[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu id
On Wed, Dec 10, 2014 at 10:29:46AM +0000, Jan Beulich wrote: > >>> On 10.12.14 at 07:00, <msw@xxxxxxxxx> wrote: > > On Thu, Nov 06, 2014 at 09:27:59PM +0000, Andrew Cooper wrote: > >> On 06/11/2014 19:32, Konrad Rzeszutek Wilk wrote: > >> > On Thu, Nov 06, 2014 at 03:07:10PM +0000, Paul Durrant wrote: > >> >> To perform certain hypercalls HVM guests need to use Xen's idea of > >> > What are those 'certain'? > >> > >> Some HVM hypercalls take a vcpu_id as a parameter. See the > >> functionally-unrelated-but-companion patch "x86/hvm: Add per-vcpu evtchn > >> upcalls". > >> > >> HVM guests currently have no way of obtaining a xen vcpu_id for a given > >> vcpu, and therefore have no way of passing an appropriate parameter to > >> the hypercalls. > > > > Sorry for chiming in late... > > > > That's not strictly true. You can use the processor index in ACPI. > > Not really, no. The ACPI tables get created by hvmloader, without > regard to Xen vCPU numbering afaict. The ACPI tables created by hvmloader must take Xen vCPU numbering into regard, at last as a consideration as both hvmloader and the hypervisor share this "vcpu_id * 2" math for assigning APIC IDs. > >> >> vcpu id, which may well not match the guest OS idea of CPU id. > >> > Can you elaborate more on the use case please? And why > >> > only restrict this to HVM guests? Why not PV? > >> > >> PV guests unconditionally know their vcpu_id's right from the start, and > >> indeed need them to bring up APs. HVM guests currently only know APIC IDs. > > > > No, don't assume anything about APIC IDs mapping to Xen virtual > > processor index. This will break things on EC2 instances that expose > > proper CPU topology through CPUID, and this does *not* follow the > > "index * 2" formula. > > Hmm, you say "no" first, but the rest of your statement seems to > agree with what Andrew was saying... I say "no" because the guest has more to work on than APIC IDs. It has ACPI processor object IDs. > >> >> This patch adds vcpu id to the HVM cpuid leaf allowing the guest > >> >> to build a mapping. > >> > Don't we have existing hypercalls to get this? Ah VCPUOP_get_physid > >> > is what I was thinking of and that does not seem to be what > >> > you want? > >> > >> This hypercall is only valid for pinned vcpus (i.e. only dom0 with > >> opt_dom0_vcpus_pin), and gives back the underlying APIC ID, and the ACPI > >> processor ID for that APIC ID. > >> > >> The APIC ID can be obtained from cpuid as the vcpus are pinned, and the > >> ACPI ID can be obtained from the ACPI tables, as the domain is dom0. > >> Ergo, this hypercall is quite redundant, has nothing at all to do with > >> the problem Paul is trying to solve, and appears buggy as it hands back > >> two 64bit values, shifted 32bits apart, in a 64bit integer. > > > > And the Xen vCPU index can be determined by the processor object IDs > > in DSDT. > > I hope you don't have code doing so, as such an association isn't > pinned down anywhere in the ABI afaik. I think that both Linux and FreeBSD are using the enumeration of CPUs in ACPI tables to derive the vCPU ID needed for HYPERVISOR_vcpu_op hypercalls. For Linux, we use smp_processor_id() to get the vCPU ID. This, as far as I know, will enumerate as CPUs are presented in ACPI tables (where CPU 0, the boot CPU, will return 0 for smp_processor_id() and so on.). --msw _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |