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

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

On Thu, Jun 25, 2015 at 08:34:45AM +0100, Jan Beulich wrote:
> >>> On 24.06.15 at 17:59, <konrad.wilk@oracle.com> 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
>