From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
Jan Beulich <JBeulich@suse.com>
Cc: ian.jackson@eu.citrix.com, xen-devel@lists.xen.org,
Paul Durrant <paul.durrant@citrix.com>,
wei.liu2@citrix.com, roger.pau@citrix.com
Subject: Re: [PATCH v2 08/11] pvh/acpi: Handle ACPI accesses for PVH guests
Date: Wed, 16 Nov 2016 19:00:03 -0500 [thread overview]
Message-ID: <7df262e4-1d96-b56d-f17e-e5c78cb3fc0d@oracle.com> (raw)
In-Reply-To: <8d335b19-87e4-11a9-603e-53352136d854@oracle.com>
>
> When we want to enable ACPI vcpu hotplug for HVM guests,
>>> What do you mean by "when"? We *are* doing ACPI hotplug for HVM guests,
>>> aren't we?
>> Are we? If so, how?
>>
>> I don't see any toolstack or qemu code able to cope with APCI CPU
>> hotplug. I can definitely see ACPI PCI hotplug in qemu, but that does
>> make sense.
> piix4_acpi_system_hot_add_init():
> acpi_cpu_hotplug_init(parent, OBJECT(s), &s->gpe_cpu,
> PIIX4_CPU_HOTPLUG_IO_BASE);
>
>
>>> Or are you thinking about moving this functionality to the hypervisor?
>> As an aside, we need to move some part of PCI hotplug into the
>> hypervisor longterm. At the moment, any new entity coming along and
>> attaching to an ioreq server still needs to negotiate with Qemu to make
>> the device appear. This is awkward but doable if all device models are
>> in dom0, but is far harder if the device models are in different domains.
>>
>> As for CPU hotplug, (if I have indeed overlooked something), Qemu has no
>> business in this matter.
> Yes. And if we are going to do it for PVH we might as well do it for HVM
> --- I think most of the code will be the same, save for how SCI is sent.
So I discovered that we actually cannot unplug an HVM VCPU with qemu,
there is no support for that via QMP (which is what we use).
'xl vcpu-set <domid> N' is nop when we unplug.
-boris
>
> -boris
>
>> The device model exists to be an
>> implementation of an LPC bridge, and is not responsible for any CPU
>> related functionality; Xen does all vcpu handling.
>>
>>
>> The Xen project and community have had a very rich history of hacking
>> things up in the past, an frankly, it shows. I want to ensure that
>> development progresses in an architecturally clean and appropriate
>> direction, especially if this enables us to remove some of the duck tape
>> holding pre-existing features together.
>>
>> ~Andrew
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-11-17 0:00 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-09 14:39 [PATCH v2 00/11] PVH VCPU hotplug support Boris Ostrovsky
2016-11-09 14:39 ` [PATCH v2 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus Boris Ostrovsky
2016-11-09 15:04 ` Andrew Cooper
2016-11-09 15:29 ` Boris Ostrovsky
2016-11-09 19:23 ` Andrew Cooper
2016-11-09 19:47 ` Boris Ostrovsky
2016-11-14 14:59 ` Boris Ostrovsky
2016-11-14 17:17 ` Andrew Cooper
2016-11-14 17:48 ` Boris Ostrovsky
2016-11-14 18:19 ` Andrew Cooper
2016-11-14 18:44 ` Boris Ostrovsky
2016-11-15 16:41 ` Andrew Cooper
2016-11-15 17:04 ` Boris Ostrovsky
2016-11-15 17:30 ` Andrew Cooper
2016-11-15 8:34 ` Jan Beulich
2016-11-15 14:28 ` Boris Ostrovsky
2016-11-15 14:33 ` Jan Beulich
2016-11-15 15:00 ` Boris Ostrovsky
2016-11-09 14:39 ` [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests Boris Ostrovsky
2016-11-09 14:48 ` Julien Grall
2016-11-09 14:54 ` Boris Ostrovsky
2016-11-09 14:48 ` Paul Durrant
2016-11-09 14:59 ` Andrew Cooper
2016-11-09 15:14 ` Boris Ostrovsky
2016-11-09 19:58 ` Andrew Cooper
2016-11-09 21:01 ` Boris Ostrovsky
2016-11-14 15:01 ` Boris Ostrovsky
2016-11-14 17:19 ` Andrew Cooper
2016-11-15 8:47 ` Jan Beulich
2016-11-15 14:47 ` Boris Ostrovsky
2016-11-15 15:13 ` Jan Beulich
2016-11-15 15:41 ` Boris Ostrovsky
2016-11-15 15:53 ` Jan Beulich
2016-11-15 16:23 ` Boris Ostrovsky
2016-11-15 16:33 ` Jan Beulich
2016-11-15 16:58 ` Boris Ostrovsky
2016-11-15 16:59 ` Jan Beulich
2016-11-15 18:31 ` Andrew Cooper
2016-11-09 14:39 ` [PATCH v2 03/11] pvh: Set online VCPU map to avail_vcpus Boris Ostrovsky
2016-11-11 19:57 ` Konrad Rzeszutek Wilk
2016-11-12 15:40 ` Wei Liu
2016-11-09 14:39 ` [PATCH v2 04/11] acpi: Make pmtimer optional in FADT Boris Ostrovsky
2016-11-15 8:49 ` Jan Beulich
2016-11-09 14:39 ` [PATCH v2 05/11] acpi: Power and Sleep ACPI buttons are not emulated for PVH guests Boris Ostrovsky
2016-11-11 19:56 ` Konrad Rzeszutek Wilk
2016-11-15 8:54 ` Jan Beulich
2016-11-09 14:39 ` [PATCH v2 06/11] acpi: PVH guests need _E02 method Boris Ostrovsky
2016-11-11 19:58 ` Konrad Rzeszutek Wilk
2016-11-15 8:57 ` Jan Beulich
2016-11-09 14:39 ` [PATCH v2 07/11] pvh/ioreq: Install handlers for ACPI-related PVH IO accesses Boris Ostrovsky
2016-11-09 14:56 ` Paul Durrant
2016-11-11 20:01 ` Konrad Rzeszutek Wilk
2016-11-15 9:04 ` Jan Beulich
2016-11-09 14:39 ` [PATCH v2 08/11] pvh/acpi: Handle ACPI accesses for PVH guests Boris Ostrovsky
2016-11-09 14:58 ` Paul Durrant
2016-11-11 20:07 ` Konrad Rzeszutek Wilk
2016-11-15 9:24 ` Jan Beulich
2016-11-15 14:55 ` Boris Ostrovsky
2016-11-15 15:17 ` Jan Beulich
2016-11-15 15:44 ` Boris Ostrovsky
2016-11-15 15:56 ` Jan Beulich
2016-11-15 19:19 ` Andrew Cooper
2016-11-15 19:38 ` Boris Ostrovsky
2016-11-15 20:07 ` Andrew Cooper
2016-11-15 20:20 ` Boris Ostrovsky
2016-11-17 0:00 ` Boris Ostrovsky [this message]
2016-11-17 0:08 ` Andrew Cooper
2016-11-16 9:23 ` Jan Beulich
2016-11-09 14:39 ` [PATCH v2 09/11] events/x86: Define SCI virtual interrupt Boris Ostrovsky
2016-11-15 9:29 ` Jan Beulich
2016-11-09 14:39 ` [PATCH v2 10/11] pvh: Send an SCI on VCPU hotplug event Boris Ostrovsky
2016-11-15 9:36 ` Jan Beulich
2016-11-15 14:57 ` Boris Ostrovsky
2016-11-15 15:18 ` Jan Beulich
2016-11-15 9:38 ` Jan Beulich
2016-11-09 14:39 ` [PATCH v2 11/11] docs: Describe PVHv2's VCPU hotplug procedure Boris Ostrovsky
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=7df262e4-1d96-b56d-f17e-e5c78cb3fc0d@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=paul.durrant@citrix.com \
--cc=roger.pau@citrix.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).