Re: [Xen-devel] PCI BAR register space written with garbage in HVM guest.

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

> <aside>
> What is pcifront/pciback's role for HVM guests exactly?  I understand

None functionaly. The purpose is to "bind" the PCI devices to pciback
(or pcistub) so that no other kernel module usurps it and starts
utilizing it.

> that you "hide" the devices from the dom0 with pciback and it
> definately loads and does *something* when the HVM guest comes up, but
> accesses from the domU don't appear to go through it at all (I
> understand that it works with qemu somehow, but that channel too is
> not at all clear how it works...)

With HVM pciback is not used. You need an virtualization aware IOMMU to
pass through PCI devices to the guest. PCIback/PCI front is for PV
guests and on machine where you don't neccessarily have this fancy
IOMMU.

> I've looked through qemu enough to kind of understand that it's
> responsible for abstracting the PCI configuration space for the domU,
> but I don't really understand how accesses get channeled through to it
> from the domU.  Does it use hypercalls somehow?  Can someone explain

The Hypervisor gets "trapped" when an outb is made (look for
emulate_privileged_op function and specifically out).

Then it somehow injects the fault in QEMU which does the rest. I don't
remember the details of how it does thought :-(

> how this whole flow is supposed to work for PCI configuration space
> accesses?
> </aside>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel