[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/2] hvmloader: don't hard-code IO-APIC parameters



>>> On 17.06.16 at 13:51, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 06/17/2016 02:00 AM, Jan Beulich wrote:
>>>>> On 16.06.16 at 18:49, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>> On 06/16/2016 05:40 AM, Jan Beulich wrote:
>>>> The IO-APIC address has variable bits determined by the PCI-to-ISA
>>>> bridge, and the IO-APIC version should be read from the IO-APIC. (Note
>>>> that there's still implicit rather than explicit agreement on the
>>>> IO-APIC base address between qemu and the hypervisor.)
>>> It probably doesn't matter now for PVHv2 since we are not going to
>>> initially emulate IOAPIC but when/if we do, how do we query for base
>>> address and version? Should we just rely on the same implicit agreement?
>> If this refers to the sentence in parentheses, then this was really
>> meant to indicate a work item. I.e. qemu should negotiate with
>> Xen. For PVHv2 this would then probably mean for hvmloader to
>> query Xen (via new hypercall).
> 
> We are not using hvmloader for PVH so I am not sure how that would work.
> You mean the toolstack?

Oh, right. Whoever puts the ACPI tables in place.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.