[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH QEMU-XEN] xen/pt: Start with emulated PCI_COMMAND set to zero.
On Thu, Jun 25, 2015 at 08:34:45AM +0100, Jan Beulich wrote: > >>> On 24.06.15 at 17:59, <konrad.wilk@xxxxxxxxxx> 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 > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |