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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.06.15 at 19:23, <konrad.wilk@xxxxxxxxxx> wrote:
> 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.

Ah, right - cases like the above would either indeed need the change
you suggest, or latching the needed value(s) individually before they
may get modified by guest field initialization.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel