>>> On 01.04.16 at 15:54, <paul.durr...@citrix.com> wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 01 April 2016 14:43 >> >>> On 01.04.16 at 15:01, <paul.durr...@citrix.com> wrote: >> >> From: Jan Beulich [mailto:jbeul...@suse.com] >> >> Sent: 01 April 2016 12:21 >> >> >>> On 01.04.16 at 12:56, <paul.durr...@citrix.com> wrote: >> >> >> From: Jan Beulich [mailto:jbeul...@suse.com] >> >> >> Sent: 01 April 2016 10:59 >> >> > I guess it could be handled entirely in Xen if we are willing to snoop >> >> > on >> >> > PCI configuration. It would not be too hard to snoop guest writes to the >> >> BARs >> >> > in config space so that Xen can keep track of where they are. Snooping >> on >> >> the >> >> > MSI-X capability could then tell Xen when to start interposing on the >> table, >> >> > and allow it to discover the GPA at that point (via the BIR and offset >> >> > values). >> >> >> >> Well, that's a possibility, but won't - afaict - work without qemu's >> >> help at another point: So far we don't know the guest's PCI bus >> >> topology, hence we can't correlate vBAR writes we might snoop >> >> with the physical devices they correspond to. >> > >> > Does Xen need to know that correspondence just to track state? I thought >> the >> > problem here was that Xen does not see every guest access to an MSI-X >> table. >> > If Xen always interposes on MSI-X tables then it can at least track the > state >> > of the emulated table, even if we end up just forwarding the access for >> QEMU >> > to handle at first. When the mapping is created to the actual h/w table >> then, >> > presumably, Xen's idea of state should correspond to QEMU's. >> >> But Xen doesn't see the guest view of config space, > > Well Xen interposes on every single config cycle so arguably it sees exactly > what the guest sees.
Ah, so you mean to snoop what qemu returns. Yes, that would be an option. >> And additionally msixtbl_addr_to_desc() needs to know the physical >> device. > > Yes, but msixtbl_range() could be trivially changed to accept any access > where msixtbl_find_entry() returns non-NULL. That would allow msixtbl_write() > to manipulate entry->flags even if msixtbl_addr_to_desc() returns NULL. Are you looking at some old code base? There's no entry->flags manipulation. We call guest_mask_msi_irq(), and for that we need to know the IRQ descriptor, which in turn requires knowing the pdev (for msixtbl_addr_to_desc() to return non-NULL). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
