[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |