From: Chao Gao <chao.gao@intel.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
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>,
Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [RFC PATCH 1/8] x86/domctl: introduce a pair of hypercall to set and get cpu topology
Date: Wed, 10 Jan 2018 03:51:08 +0800 [thread overview]
Message-ID: <20180109195107.GA37862@op-computing> (raw)
In-Reply-To: <f1fbdab3-2fc9-2158-3f9b-5838e8aae3ce@tycho.nsa.gov>
On Tue, Jan 09, 2018 at 12:18:13PM -0500, Daniel De Graaf wrote:
>On 01/09/2018 04:06 AM, Chao Gao wrote:
>> On Mon, Jan 08, 2018 at 01:14:44PM -0500, Daniel De Graaf wrote:
>> > On 01/07/2018 11:01 PM, 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>
>> >
>> > When adding new XSM controls for use by device models, you also
>> > need to add the permissions to the device_model macro defined in
>> > tools/flask/policy/modules/xen.if. If domains need to call this
>> > function on themselves (is this only true for get?), you will also
>> > need to add it to declare_domain_common.
>> >
>>
>> Hi, Daniel.
>>
>> Yes. XENMEM_get_cpu_topology will be called by the domain itself.
>> And Both get and set will be called by dom0 when creating one domain.
>> So I need:
>> 1. add *set* and *get* to create_domain_common.
>> 2. add *set* to declare_domain_common.
>>
>> Is it right?
>>
>> Thanks
>> Chao
>
>It sounds like you need to add get to declare_domain_common (not set)
>because the domain only needs to invoke this on itself. If the device
>model doesn't need to use these hypercalls (would guest cpu hotplug or
>similar things need them?), then that's all you need to add.
Got it. I will first recognize whether device model needs these
hypercalls. If yes, make changes to macro device_model accordingly.
Thanks
chao
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-01-09 19:51 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 [this message]
2018-01-09 23:47 ` Andrew Cooper
2018-01-09 20:47 ` Chao Gao
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=20180109195107.GA37862@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.