|
[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 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.
> 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 |