"xl vcpu-set" not persistent across reboot?

Commit Message

Wei Liu June 14, 2016, 5:23 p.m. UTC

On Tue, Jun 14, 2016 at 06:03:01PM +0100, Wei Liu wrote:
> On Tue, Jun 14, 2016 at 05:57:00PM +0100, Ian Jackson wrote:
> > Wei Liu writes ("Re: [Xen-devel] "xl vcpu-set" not persistent across reboot?"):
> > > What Andrew means is that QEMU shouldn't have kept the CPU state
> > > structures in the first place. My response explains why that is not
> > > possible from a QEMU upstream point of view.
> > 
> > I don't think it addresses my point.
> > 
> > > Hence the unfortunate fact is that we need to live with it for now. To
> > > start QEMU we need to create a bunch of dummy CPUs to keep QEMU happy.
> > > All those dummy states need to be kept.
> > 
> > Why do we need one dummy state per actual vcpu rather than just one
> > dummy state no matter how many vcpus ?
> > 
> 
> We can't because ...
> 
> > Or is qemu involved in hvm cpu hotplug ?
> > 
> 
> when doing hotplug, libxl uses QMP command to tell QEMU to create
> CPUs.
> 
> Whether this can be changed I will let Anthony and Stefano to answer.
> 

OK, a quick check shows that the current state of affairs does require
QEMU to get involved.

If we skip the QMP call, guest gets no new cpus -- CPU hotplug is
completely broken.

Wei.

---8<---

> Wei.
> 
> > Ian.

Patch

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 0e2c15a..1cd8e00 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5756,6 +5756,8 @@  static int libxl__set_vcpuonline_qmp(libxl__gc
*gc, uint32_t domid,
     int i, rc;
     libxl_bitmap current_map, final_map;
 
+    return 0;
+
     libxl_bitmap_init(&current_map);
     libxl_bitmap_init(&final_map);