Re: [Xen-devel] [PATCH] x86/hvm: Extend HVM cpuid leaf with vcpu id

[Matt Wilson <msw@xxxxxxxxx>]

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