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: Thu, 25 Jun 2015 13:23:14 -0400 Message-ID: <20150625172313.GA2470@x230.dumpdata.com> References: <5578438C020000780008309D@mail.emea.novell.com> <1433969591-11202-1-git-send-email-konrad@kernel.org> <557959430200007800083634@mail.emea.novell.com> <557FED6C02000078000853EE@mail.emea.novell.com> <20150624155935.GA7912@l.oracle.com> <558BCB350200007800089529@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z8AsC-0001VW-Qw for xen-devel@lists.xenproject.org; Thu, 25 Jun 2015 17:23:36 +0000 Content-Disposition: inline In-Reply-To: <558BCB350200007800089529@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, konrad@kernel.org, linux@eikelenboom.it, david.vrabel@citrix.com, xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On Thu, Jun 25, 2015 at 08:34:45AM +0100, Jan Beulich wrote: > >>> On 24.06.15 at 17:59, wrote: > > While digging in this I realized that some shortcuts and assumptions > > had been taken (I think I am restating what you two have already > > realized). > > > > 1) The dev.config is (by Xen code) used as the cache of the > > host configuration devices (which is OK at init right now). > > > > However to sync up the ->data with dev.config (and apply emu_mask) > > means that it cannot be used as such (the semantics of that have > > changed). > > > > 2). The dev.config is (by the generic code) used as a view of what > > the guest should see (cache of guest values). > > > > > > To make this work, the plan would be: > > > > 1). Remove all the dev.config accesses to check host values: > > @@ -728,7 +729,7 @@ static int xen_pt_initfn(PCIDevice *d) > > } > > > > /* Bind interrupt */ > > - if (!s->dev.config[PCI_INTERRUPT_PIN]) { > > + if (xen_host_pci_get_byte(PCI_INTERRUPT_PIN)) { > > XEN_PT_LOG(d, "no pin interrupt\n"); > > goto out; > > } > > And replace them with calls to get the actual host value. > > > > 2). Replace all the pci_get_[byte,word,long] (which are wrappers > > around dev.config) in the init routines (see get_capability_version and > > xen_pt_linkctrl_reg_init) with calls to xen_host_pci_[byte,word,long]. > > > > In short - replace the calls to get the actual host values. > > > > That would untangle a lot of this and make it a bit saner (I hope). > > Except that I don't think changing the init-time uses would really be > necessary. Ah, but how would we go forward when dev.config is all we have - without any 'data'? We have to stash the init guest values somewhere. > > > And after that I can: > > > > 3). Rip out ->data and use pci_set_[byte,word,long] or > > pci_get_[byte,word,long] > > to get one unified view of what the guest is suppose to have. > > > > 4). Tackle bugs that will creep up because of this. I am not sure what > > they are, but surely will hit some. I expect that some of these > > patches will add debug/more logging to help me tackle this. > > > > 5). Reinstate an host cache (if needed) for configuration access to lessen > > the amount of reads we do. 'host_cache_config' perhaps? > > Not sure it's a good idea to cache registers that can change behind > our back. > > Jan >