From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH QEMU-XEN] xen/pt: Start with emulated PCI_COMMAND set to zero. Date: Fri, 12 Jun 2015 09:37:31 -0400 Message-ID: <20150612133731.GE15651@l.oracle.com> References: <5578438C020000780008309D@mail.emea.novell.com> <1433969591-11202-1-git-send-email-konrad@kernel.org> <557959430200007800083634@mail.emea.novell.com> <1593167293.20150611131934@eikelenboom.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z3P9T-00069G-Bn for xen-devel@lists.xenproject.org; Fri, 12 Jun 2015 13:37:43 +0000 Content-Disposition: inline In-Reply-To: <1593167293.20150611131934@eikelenboom.it> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Sander Eikelenboom Cc: stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, konrad@kernel.org, david.vrabel@citrix.com, Jan Beulich , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org 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, 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 > > >