[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Is: qemu-xen mishandling upper 64-bit BAR compared to qemu-tradWas:Re: Dom0 linux 4.0 + devel/for-linus-4.1 branch: p2m.c:884:d0v0 gfn_to_mfn failed! gfn=ffffffff001ed type:4
>>> On 10.06.15 at 03:02, <konrad.wilk@xxxxxxxxxx> wrote: > The problem is that the XSA120-addendm patch (which does not clear > the PCI_COMMAND register anymore), causes an missing functionality in > qemu-xen to be exposed. This missing functionality is implemented in > qemu-traditional which is why it works there. > > The problem is that qemu-xen for any write to the BAR regions > updates them to the hypervisor - but only if the real hardware has > them enabled (see pci_update_mappings in pci_default_write_config which > is called by xen_pt_pci_write_config). Specifically pci_bar_address > checks PCI_COMMAND register for PCI_COMMAND_MEMORY. If it is disabled > (so no XSA-120 addendum patch), it returns -1 (default value resulting > in no changes in the internal structures). If it is enabled, then > it updates the d->config space with the value written by the guest. > Once xen_pt_pci_write_config is done it syncs up the changes (if there > are any) which results in the QEMU calling hypervisor to update the P2M > mapping. There's one fundamental aspect I'm not understanding here: pci_update_mappings() / pci_bar_address() look at the guest view (or at least they ought to be), and the virtual command register starts out as zero. Is the bug perhaps that xen_pt_initfn(), after having initialized d->config[] via xen_host_pci_get_block(), leaves the command register at its host view value (rather than updating it alongside reg_entry->data in xen_pt_config_reg_init(), called via xen_pt_config_init()), which would have happened to be zero without that XSA-120 addendum? It is of course concerning that there are two (now clearly mismatching) guest views within qemu (and along those lines I also wonder whether the apparent duplicate maintenance of MSI and MSI-X state, due to pci_default_write_config() calling msi{,x}_write_config(), can do any good, or why the code uses pci_default_write_config() but not pci_default_read_config()). It looks to me as if there was a halfhearted attempt to utilize infrastructure already available in qemu when these Xen pieces got added, leading to hard to understand issues like the one here. I.e. even if we addressed the initialization value issue above, there would still be two competing emulation layers potentially (and I suppose quite likely) leading to differing register state later on. Hence I wonder how many more issues there are (to come)... Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |