Re: [PATCH QEMU-XEN] xen/pt: Start with emulated PCI_COMMAND set to zero.

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Thu, Jun 11, 2015 at 01:19:34PM +0200, Sander Eikelenboom wrote:
> 
> Thursday, June 11, 2015, 9:47:47 AM, you wrote:
> 
> >>>> On 10.06.15 at 22:53, <konrad@kernel.org> wrote:
> >> --- a/hw/xen/xen_pt.c
> >> +++ b/hw/xen/xen_pt.c
> >> @@ -785,7 +785,9 @@ out:
> >>          xen_host_pci_set_word(&s->real_device, PCI_COMMAND,
> >>                                pci_get_word(d->config + PCI_COMMAND) | cmd);
> >>      }
> >> -
> >> +    /* Until the guest enables the device use d->config values which will
> >> +     * inhibit pci_bar_address & pci_update_mappings from triggering updates.*/
> >> +    pci_set_word(d->config + PCI_COMMAND, 0);
> >>      memory_listener_register(&s->memory_listener, &address_space_memory);
> >>      memory_listener_register(&s->io_listener, &address_space_io);
> >>      XEN_PT_LOG(d,
> 
> > Well, I can see this as something to be tried out as an experiment,
> > but it looks like you mean this to be a proper submission for
> > inclusion upstream? Or maybe not, considering that qemu-devel

I needed to make sure that Sander's test-case is indeed fixed with this.
And it looks like it is which makes further development of this
much simpler since I can reproduce this.

> > wasn't even Cc-ed? In any case - what we need here is a general
> > solution to at least the initialization part of the problem, i.e. all
> > fields we emulate some or all bits for need to have d->config[]
> > updated accordingly (i.e. you need to merge d->config[] and
> > XenPTReg's data field based on the respective XenPTRegInfo's
> > emu_mask, but perhaps simply copying the data field to
> d->>config[] would have the same effect; if it doesn't, we have
> > yet another problem). For the command register this for example
> > means that it is in no way guaranteed that it would end up being
> > zero; its emu_mask however guarantees that the memory and I/O
> > decode bits would start out as zero (which is what you're after).

Right, I hope :-)
> 
> Just tested this patch together with a dom0 kernel which has the dropped kernel patch from Konrad:
> 22d8a8938407cb1342af763e937fdf9ee8daf24a xen/pciback: Don't disable PCI_COMMAND on PCI device reset.
> 
> And this patch does help to prevent the issue from happening.

Yeeey!
>  
> --
> Sander
> 
> > Jan
> 
> 
>