All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chao Gao <chao.gao@intel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	xen-devel@lists.xen.org, Jan Beulich <jbeulich@suse.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [RFC PATCH 1/8] x86/domctl: introduce a pair of hypercall to set and get cpu topology
Date: Wed, 10 Jan 2018 04:47:26 +0800	[thread overview]
Message-ID: <20180109204725.GB37862@op-computing> (raw)
In-Reply-To: <eaeb4016-0534-afa2-fcce-8146bfcdc160@citrix.com>

On Tue, Jan 09, 2018 at 11:47:54PM +0000, Andrew Cooper wrote:
>On 08/01/18 04:01, Chao Gao wrote:
>> Define interface, structures and hypercalls for toolstack to build
>> cpu topology and for guest that will retrieve it [1].
>> Two subop hypercalls introduced by this patch:
>> XEN_DOMCTL_set_cpu_topology to define cpu topology information per domain
>> and XENMEM_get_cpu_topology to retrieve cpu topology information.
>>
>> [1]: during guest creation, those information helps hvmloader to build ACPI.
>>
>> Signed-off-by: Chao Gao <chao.gao@intel.com>
>
>I'm sorry, but this going in the wrong direction.  Details like this
>should be contained and communicated exclusively in the CPUID policy.
>
>Before the spectre/meltdown fire started, I had a prototype series
>introducing a toolstack interface for getting and setting a full CPUID
>policy at once, rather than piecewise.  I will be continuing with this

Is the new interface able to set CPUID policy for each vCPU rather than
current for each domain? Otherwise I couldn't see how to set APIC_ID
for each vcpu except by introducing a new interface.

>work once the dust settles.
>
>In particular, we should not have multiple ways of conveying the same
>information, or duplication of the same data inside the hypervisor.
>
>If you rearrange your series to put the struct cpuid_policy changes
>first, then patch 2 will become far more simple.  HVMLoader should
>derive its topology information from the CPUID instruction, just as is
>expected on native hardware.

Good point. It seems that in HVMLoader BSP should boot APs in a
broadcase fashion and then information is collected via CPUID and then
build MADT/SRAT.

Thanks
Chao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-01-09 20:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-08  4:01 [RFC PATCH 0/8] Add guest CPU topology support Chao Gao
2018-01-08  4:01 ` [RFC PATCH 1/8] x86/domctl: introduce a pair of hypercall to set and get cpu topology Chao Gao
2018-01-08 18:14   ` Daniel De Graaf
2018-01-09  9:06     ` Chao Gao
2018-01-09 17:18       ` Daniel De Graaf
2018-01-09 19:51         ` Chao Gao
2018-01-09 23:47   ` Andrew Cooper
2018-01-09 20:47     ` Chao Gao [this message]
2018-01-10  9:09       ` Andrew Cooper
2018-04-23 16:00   ` Jan Beulich
2018-01-08  4:01 ` [RFC PATCH 2/8] x86/vlapic: use apic_id array to set initial (x2)APIC ID Chao Gao
2018-04-23 16:04   ` Jan Beulich
2018-04-24  7:53     ` Chao Gao
2018-04-24  8:26       ` Jan Beulich
2018-01-08  4:01 ` [RFC PATCH 3/8] xl/parse: introduce cpu_topology to guest config Chao Gao
2018-01-08  4:01 ` [RFC PATCH 4/8] libxl: calculate and set vcpu topology Chao Gao
2018-01-08  4:01 ` [RFC PATCH 5/8] xen/mem: handle XENMEM_get_cpu_topology in compat_memory_op Chao Gao
2018-01-08  4:01 ` [RFC PATCH 6/8] hvmloader: get CPU topology information from hypervisor Chao Gao
2018-01-08  4:01 ` [RFC PATCH 7/8] libacpi: build madt/srat according cpu topology Chao Gao
2018-01-08  4:01 ` [RFC PATCH 8/8] x86/cpuid: emulate extended topology enumeration leaf Chao Gao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180109204725.GB37862@op-computing \
    --to=chao.gao@intel.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=sstabellini@kernel.org \
    --cc=tim@xen.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.