On Fri, 2011-10-07 at 17:01 +0100, Anthony PERARD wrote:
> On Fri, Oct 7, 2011 at 13:43, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Fri, 2011-10-07 at 13:10 +0100, Anthony PERARD wrote:
> >> This function insert a PCI passthrough device in qemu.
> >>
> >> Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
> >> ---
> >> tools/libxl/libxl_internal.h | 2 +
> >> tools/libxl/libxl_qmp.c | 89
> >> ++++++++++++++++++++++++++++++++++++++++++
> >> 2 files changed, 91 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> >> index 4dd0f91..78e1be2 100644
> >> --- a/tools/libxl/libxl_internal.h
> >> +++ b/tools/libxl/libxl_internal.h
> >> @@ -119,6 +119,7 @@ typedef struct {
> >> } libxl__device;
> >>
> >> #define XC_PCI_BDF "0x%x, 0x%x, 0x%x, 0x%x"
> >> +#define PCI_DEVFN(slot, func) ((((slot) & 0x1f) << 3) | ((func) & 0x07))
> >
> > No need to include the domain or dev in this? The name is pretty weird
> > if you don't include the dev portion. Looks like this is actually a
> > vdevfn? xl has an open coded instance of this pattern for that -- worth
> > adding a public macro?
>
> I have actual copy the macro from qemu, and I think "slot === dev".
It appears to yes.
> I
> think the macro come from linux/pci.h.
> But yes, I use it to store the vdevfn.
>
> > FWIW pcidev_encode_bdf() exists which encodes the whole lot from a
> > libxl_device_pci, if that what you end up needing.
>
> If the vdefvn should contain the virtual bus and domain number, so
> yes, that will be the function I need.
I don't think it does in the old qemu stuff, but I don't know about
upstream, I suspect not.
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home