A bit late this week, due to my being on vacation. Normal Monday
service should be resumed next week.
Plan for a 4.2 release:
http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
The time line is as follows:
19 March -- TODO list locked down
2 April -- Feature Freeze
<< WE ARE HERE
When It's Ready -- First release candidate
Weekly -- RCN+1 until release
The updated TODO list follows.
If you are aware of any bugs which must/should be fixed for 4.2 then
please reply to this thread (otherwise I may not remember to pick them
up next week)
As well as [BUG]s I've also started tracking things to [CHECK] before
the release. These are basically for things which we ought to confirm
during the RC cycles e.g. things which are not covered by automated
testing.
Per the release plan a strong case will now have to be made as to why
new items should be added to the list, especially as a blocker, rather
than deferred to 4.3.
hypervisor, blockers:
* None
tools, blockers:
* libxl stable API -- we would like 4.2 to define a stable API
which downstream's can start to rely on not changing. Aspects of
this are:
* Interfaces which may need to be async:
* libxl_domain_suspend. Move xc_domain_save/restore into a
separate process (Ian Jackson, patches reviews and reposted).
* libxl_device_{disk,nic,vkb,add,pci}_add (and
remove). (Roger Pau Monné, patches posted for disk & nic, vkb
trivial, not looked at pci yet)
* LIBXL_NIC_TYPE enum names are confusing. (Roger, included in
calling hotplug scripts series)
* use libxl_cpumap for b_info.avail_cpus instead of an int,
this allows setting more than 31 CPUS (Yang Z Zhang, patches
posted, awaiting a repost)
* use an enum for VGA interface type (e.g. Cirrus,
StdVGA). Allows for QXL support (in 4.3). (Zhou Peng,
awaiting repost)
* xl compatibility with xm:
* [BUG] cannot create an empty CD-ROM drive on HVM guest,
reported by Fabio Fantoni in <4F9672DD.2080902@tiscali.it>
* does not automatically try to select a (set of) node(s) on
which to create a VM and pin its vcpus there. (Dario
Faggioli, v2 posted)
* More formally deprecate xm/xend. Manpage patches already in
tree. Needs release noting and communication around -rc1 to
remind people to test xl.
* calling hotplug scripts from xl (Linux and NetBSD) (Roger Pau
Monné, v6 posted, awaiting review)
* Block script support -- follows on from hotplug script (Roger
Pau Monné, "just be a matter of removing an "if"")
* Adjustments needed for qdisk backend to work on non-pvops Linux.
"qemu/xendisk: set maximum number of grants to be used" (Jan
Beulich, patch committed to qemu-xen-upstream, pending for
qemu-xen-traditional)
* [CHECK] Confirm that migration from Xen 4.1 -> 4.2 works.
* [BUG] LIBLEAFDIR et al and libfsimage do the wrong thing on
modern Debian/Ubuntu w/ multiarch capabilities (Matt Wilson,
patch posted)
* [CHECK] Test stub domains work with xl.
hypervisor, nice to have:
* PoD performance improvements (George Dunlap, and reviewed
awaiting repost)
tools, nice to have:
* xl compatibility with xm:
* Accept "xl cr /dev/null param=value" to provide all config
on the command line (W. Michael Petullo, patch posted)
* libxl stable API
* libxl_wait_for_free_memory/libxl_wait_for_memory_target.
Interface needs an overhaul, related to
locking/serialization over domain create. IanJ to add note
about this interface being substandard but otherwise defer
to 4.3.
* Interfaces which may need to be async:
* libxl_cdrom_insert. Should be easy once
disk_{add,remove} done. This is basically a helper
function and its functionality can be implemented in
terms of the libxl_disk_* interfaces. If this is not
done in time we should document as a substandard
interface which is subject to change post 4.2.
* xl.cfg(5) documentation patch for qemu-upstream
videoram/videomem support:
http://lists.xen.org/archives/html/xen-devel/2012-05/msg00250.html
qemu-upstream doesn't support specifying videomem size for the
HVM guest cirrus/stdvga. (but this works with
qemu-xen-traditional). (Pasi Kärkkäinen)
* qemu-upstream for NetBSD (Roger, patch commited to NetBSD
kernel, awaiting approval, DONE as far as Xen 4.2 is concerned)
* [BUG] long stop during the guest boot process with qcow image,
reported by Intel: http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821
* [BUG] vcpu-set doesn't take effect on guest, reported by Intel:
http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
* Load blktap driver from xencommons initscript if available, thread at:
<db614e92faf743e20b3f.1337096977@kodo2>. To be fixed more
properly in 4.3. (Patch posted, discussion, plan to take simple
xencommons patch for 4.2 and revist for 4.3)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 20/06/12 12:29, Ian Campbell wrote:> A bit late this week, due to my being on vacation. Normal Monday > service should be resumed next week. > > Plan for a 4.2 release: > http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html > > The time line is as follows: > > 19 March -- TODO list locked down > 2 April -- Feature Freeze > << WE ARE HERE > When It's Ready -- First release candidate > Weekly -- RCN+1 until release > > The updated TODO list follows. > > If you are aware of any bugs which must/should be fixed for 4.2 then > please reply to this thread (otherwise I may not remember to pick them > up next week) > > As well as [BUG]s I've also started tracking things to [CHECK] before > the release. These are basically for things which we ought to confirm > during the RC cycles e.g. things which are not covered by automated > testing. > > Per the release plan a strong case will now have to be made as to why > new items should be added to the list, especially as a blocker, rather > than deferred to 4.3. > > hypervisor, blockers: > > * NoneNot certain if this is a blocker or nice-to-have, but we have identified a regression with Xen's ability to boot, suppectedly due to c/s 25336:edd7c7ad1ad2 "x86: adjust handling of interrupts coming in via legacy vectors" on AMD hardware with an MP-BIOS bug claiming that the PIT is not connected through the IO-APIC. Fixing this is next on my todo list, and I hope to have a solution available by the end of the week. ~Andrew> > tools, blockers: > > * libxl stable API -- we would like 4.2 to define a stable API > which downstream's can start to rely on not changing. Aspects of > this are: > > * Interfaces which may need to be async: > > * libxl_domain_suspend. Move xc_domain_save/restore into a > separate process (Ian Jackson, patches reviews and reposted). > > * libxl_device_{disk,nic,vkb,add,pci}_add (and > remove). (Roger Pau Monné, patches posted for disk & nic, vkb > trivial, not looked at pci yet) > > * LIBXL_NIC_TYPE enum names are confusing. (Roger, included in > calling hotplug scripts series) > > * use libxl_cpumap for b_info.avail_cpus instead of an int, > this allows setting more than 31 CPUS (Yang Z Zhang, patches > posted, awaiting a repost) > > * use an enum for VGA interface type (e.g. Cirrus, > StdVGA). Allows for QXL support (in 4.3). (Zhou Peng, > awaiting repost) > > * xl compatibility with xm: > > * [BUG] cannot create an empty CD-ROM drive on HVM guest, > reported by Fabio Fantoni in <4F9672DD.2080902@tiscali.it> > > * does not automatically try to select a (set of) node(s) on > which to create a VM and pin its vcpus there. (Dario > Faggioli, v2 posted) > > * More formally deprecate xm/xend. Manpage patches already in > tree. Needs release noting and communication around -rc1 to > remind people to test xl. > > * calling hotplug scripts from xl (Linux and NetBSD) (Roger Pau > Monné, v6 posted, awaiting review) > > * Block script support -- follows on from hotplug script (Roger > Pau Monné, "just be a matter of removing an "if"") > > * Adjustments needed for qdisk backend to work on non-pvops Linux. > "qemu/xendisk: set maximum number of grants to be used" (Jan > Beulich, patch committed to qemu-xen-upstream, pending for > qemu-xen-traditional) > > * [CHECK] Confirm that migration from Xen 4.1 -> 4.2 works. > > * [BUG] LIBLEAFDIR et al and libfsimage do the wrong thing on > modern Debian/Ubuntu w/ multiarch capabilities (Matt Wilson, > patch posted) > > * [CHECK] Test stub domains work with xl. > > hypervisor, nice to have: > > * PoD performance improvements (George Dunlap, and reviewed > awaiting repost) > > tools, nice to have: > > * xl compatibility with xm: > > * Accept "xl cr /dev/null param=value" to provide all config > on the command line (W. Michael Petullo, patch posted) > > * libxl stable API > > * libxl_wait_for_free_memory/libxl_wait_for_memory_target. > Interface needs an overhaul, related to > locking/serialization over domain create. IanJ to add note > about this interface being substandard but otherwise defer > to 4.3. > > * Interfaces which may need to be async: > > * libxl_cdrom_insert. Should be easy once > disk_{add,remove} done. This is basically a helper > function and its functionality can be implemented in > terms of the libxl_disk_* interfaces. If this is not > done in time we should document as a substandard > interface which is subject to change post 4.2. > > * xl.cfg(5) documentation patch for qemu-upstream > videoram/videomem support: > http://lists.xen.org/archives/html/xen-devel/2012-05/msg00250.html > qemu-upstream doesn't support specifying videomem size for the > HVM guest cirrus/stdvga. (but this works with > qemu-xen-traditional). (Pasi Kärkkäinen) > > * qemu-upstream for NetBSD (Roger, patch commited to NetBSD > kernel, awaiting approval, DONE as far as Xen 4.2 is concerned) > > * [BUG] long stop during the guest boot process with qcow image, > reported by Intel: http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821 > > * [BUG] vcpu-set doesn't take effect on guest, reported by Intel: > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822 > > * Load blktap driver from xencommons initscript if available, thread at: > <db614e92faf743e20b3f.1337096977@kodo2>. To be fixed more > properly in 4.3. (Patch posted, discussion, plan to take simple > xencommons patch for 4.2 and revist for 4.3) > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel-- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>>> On 20.06.12 at 13:43, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > On 20/06/12 12:29, Ian Campbell wrote: >> hypervisor, blockers: >> >> * None > > Not certain if this is a blocker or nice-to-have, but we have identified > a regression with Xen''s ability to boot, suppectedly due to c/s > 25336:edd7c7ad1ad2 "x86: adjust handling of interrupts coming in via > legacy vectors" on AMD hardware with an MP-BIOS bug claiming that the > PIT is not connected through the IO-APIC. Fixing this is next on my > todo list, and I hope to have a solution available by the end of the week.Sure this (being a regression) is a blocker. Care to share any details, e.g. a hypervisor logs with "apic_verbosity=debug" without and with that c/s? Jan
On 20/06/12 14:07, Jan Beulich wrote:>>>> On 20.06.12 at 13:43, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >> On 20/06/12 12:29, Ian Campbell wrote: >>> hypervisor, blockers: >>> >>> * None >> Not certain if this is a blocker or nice-to-have, but we have identified >> a regression with Xen''s ability to boot, suppectedly due to c/s >> 25336:edd7c7ad1ad2 "x86: adjust handling of interrupts coming in via >> legacy vectors" on AMD hardware with an MP-BIOS bug claiming that the >> PIT is not connected through the IO-APIC. Fixing this is next on my >> todo list, and I hope to have a solution available by the end of the week. > Sure this (being a regression) is a blocker. Care to share any > details, e.g. a hypervisor logs with "apic_verbosity=debug" without > and with that c/s? > > Jan >I have not investigated yet as I am just wrapping up a more important issue, but the issue was a constant console spam saying no handler for vector 0xe5, which was causing the server to run like treacle. The issue started occurring shortly after I backported c/s 25336 to XenServer, which is why I suspect it as the culprit. Having said that, the patch appears to work fine on every other server we have, so I suspect its some motherboard quirk; it is a slightly old AMD box we have, and is 100% reproducible. I am hoping to have time to start looking at the problem this afternoon. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com
> I have not investigated yet as I am just wrapping up a more important > issue, but the issue was a constant console spam saying no handler for > vector 0xe5, which was causing the server to run like treacle. The > issue started occurring shortly after I backported c/s 25336 to > XenServer, which is why I suspect it as the culprit. Having said that, > the patch appears to work fine on every other server we have, so I > suspect its some motherboard quirk; it is a slightly old AMD box we > have, and is 100% reproducible. I am hoping to have time to start > looking at the problem this afternoon. >After some investigation, it appears that the server in question is not old (as the bug report I received said). It appears to be a fairly-new evaluation dual socket AMD box, with a beta-looking BIOS, which can''t reliably boot Xen 3.4 or Xen 4.1 (with or without the changeset), can''t reliably reboot via ACPI, and cant reliably turn back on after you cut its power. As such, I would say that the server is rather more suspect than Xen 4.2, so this IRQ issue should probably not be considered a blocker. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com
On Wed, 2012-06-20 at 20:29 +0100, Andrew Cooper wrote:> > I have not investigated yet as I am just wrapping up a more important > > issue, but the issue was a constant console spam saying no handler for > > vector 0xe5, which was causing the server to run like treacle. The > > issue started occurring shortly after I backported c/s 25336 to > > XenServer, which is why I suspect it as the culprit. Having said that, > > the patch appears to work fine on every other server we have, so I > > suspect its some motherboard quirk; it is a slightly old AMD box we > > have, and is 100% reproducible. I am hoping to have time to start > > looking at the problem this afternoon. > > > > After some investigation, it appears that the server in question is not > old (as the bug report I received said). It appears to be a fairly-new > evaluation dual socket AMD box, with a beta-looking BIOS, which can''t > reliably boot Xen 3.4 or Xen 4.1 (with or without the changeset), can''t > reliably reboot via ACPI, and cant reliably turn back on after you cut > its power. > > As such, I would say that the server is rather more suspect than Xen > 4.2, so this IRQ issue should probably not be considered a blocker.Thanks, I won''t include this issue on the list this week then. Ian.
A day late due to the Xen.org docs day yesterday. Thanks to all who
took part -- next one is July 30!
Plan for a 4.2 release:
http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
The time line is as follows:
19 March -- TODO list locked down
2 April -- Feature Freeze
<< WE ARE HERE
When It's Ready -- First release candidate
Weekly -- RCN+1 until release
The updated TODO list follows.
If you are aware of any bugs which must/should be fixed for 4.2 then
please reply to this thread (otherwise I may not remember to pick them
up next week)
Per the release plan a strong case will now have to be made as to why
new items should be added to the list, especially as a blocker, rather
than deferred to 4.3.
hypervisor, blockers:
* None
tools, blockers:
* libxl stable API -- we would like 4.2 to define a stable API
which downstream's can start to rely on not changing. Aspects of
this are:
* Interfaces which may need to be async:
* libxl_domain_suspend. Move xc_domain_save/restore into a
separate process (Ian Jackson, patches reviewed and reposted).
* libxl_device_{disk,nic,vkb,add,pci}_add (and
remove). (Roger Pau Monné, patches posted for disk & nic, vkb
trivial, not looked at pci yet)
* LIBXL_NIC_TYPE enum names are confusing. (Roger, included in
calling hotplug scripts series)
* use libxl_cpumap for b_info.avail_cpus instead of an int,
this allows setting more than 31 CPUS (Yang Z Zhang, patches
posted, awaiting a repost)
* use an enum for VGA interface type (e.g. Cirrus,
StdVGA). Allows for QXL support (in 4.3). (Zhou Peng,
awaiting repost)
* xl compatibility with xm:
* [BUG] cannot create an empty CD-ROM drive on HVM guest,
reported by Fabio Fantoni in <4F9672DD.2080902@tiscali.it>
* does not automatically try to select a (set of) node(s) on
which to create a VM and pin its vcpus there. (Dario
Faggioli, posted and reviewed, awaiting a repost)
* [CHECK] More formally deprecate xm/xend. Manpage patches already
in tree. Needs release noting and communication around -rc1 to
remind people to test xl.
* calling hotplug scripts from xl (Linux and NetBSD) (Roger Pau
Monné, posted, awaiting review)
* Block script support -- follows on from hotplug script (Roger
Pau Monné, "just be a matter of removing an "if"")
* Adjustments needed for qdisk backend to work on non-pvops Linux.
"qemu/xendisk: set maximum number of grants to be used" (Jan
Beulich, patch committed to qemu-xen-upstream, pending for
qemu-xen-traditional)
* [CHECK] Confirm that migration from Xen 4.1 -> 4.2 works.
* [BUG] LIBLEAFDIR et al and libfsimage do the wrong thing on
modern Debian/Ubuntu w/ multiarch capabilities (Matt Wilson,
patch posted)
* [BUG] stub domains broken. HVM_PARAM_DM_DOMAIN needs to reset
HVM_PARAM_BUFIOREQ_EVTCHN (Ian Campbell, Anthony Perard)
hypervisor, nice to have:
* PoD performance improvements (George Dunlap, and reviewed
awaiting repost)
tools, nice to have:
* xl compatibility with xm:
* Accept "xl cr /dev/null param=value" to provide all config
on the command line (W. Michael Petullo, patch posted)
* libxl stable API
* libxl_wait_for_free_memory/libxl_wait_for_memory_target.
Interface needs an overhaul, related to
locking/serialization over domain create. IanJ to add note
about this interface being substandard but otherwise defer
to 4.3.
* Interfaces which may need to be async:
* libxl_cdrom_insert. Should be easy once
disk_{add,remove} done. This is basically a helper
function and its functionality can be implemented in
terms of the libxl_disk_* interfaces. If this is not
done in time we should document as a substandard
interface which is subject to change post 4.2.
* xl.cfg(5) documentation patch for qemu-upstream
videoram/videomem support:
http://lists.xen.org/archives/html/xen-devel/2012-05/msg00250.html
qemu-upstream doesn't support specifying videomem size for the
HVM guest cirrus/stdvga. (but this works with
qemu-xen-traditional). (Pasi Kärkkäinen)
* [BUG] long stop during the guest boot process with qcow image,
reported by Intel: http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821
* [BUG] vcpu-set doesn't take effect on guest, reported by Intel:
http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
* Load blktap driver from xencommons initscript if available, thread at:
<db614e92faf743e20b3f.1337096977@kodo2>. To be fixed more
properly in 4.3. (Patch posted, discussion, plan to take simple
xencommons patch for 4.2 and revist for 4.3)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Tue, Jun 26, 2012 at 01:39:42AM -0700, Ian Campbell wrote:> * [BUG] vcpu-set doesn''t take effect on guest, reported by Intel: > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822This may be a problem with the guest, rather than a problem with Xen or the toolstack. I tested on a domU running a 3.2.20-based Linux kernel. The domU kernel didn''t automatically enable the vCPUs after calling "xl vcpu-set" to increase the allocation. # xl list 2 Name ID Mem VCPUs State Time(s) test 2 15360 1 -b---- 6617.6 # xl vcpu-set 2 4 # xl list 2 Name ID Mem VCPUs State Time(s) test 2 15360 1 -b---- 6617.7 But when I hotplugged the CPUs on the domU side with for online in /sys/devices/system/cpu/cpu*/online; do echo 1 > $online done Now we see: # xl list 2 Name ID Mem VCPUs State Time(s) test 2 15360 4 -b---- 6617.8 I''ve added this as a comment to the bugzilla. Matt
On Tue, Jun 26, 2012 at 01:31:51PM -0700, Matt Wilson wrote:> On Tue, Jun 26, 2012 at 01:39:42AM -0700, Ian Campbell wrote: > > * [BUG] vcpu-set doesn''t take effect on guest, reported by Intel: > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822 > > This may be a problem with the guest, rather than a problem with Xen > or the toolstack. I tested on a domU running a 3.2.20-based Linux > kernel. The domU kernel didn''t automatically enable the vCPUs after > calling "xl vcpu-set" to increase the allocation. > > # xl list 2 > Name ID Mem VCPUs State Time(s) > test 2 15360 1 -b---- 6617.6 > # xl vcpu-set 2 4 > # xl list 2 > Name ID Mem VCPUs State Time(s) > test 2 15360 1 -b---- 6617.7 > > But when I hotplugged the CPUs on the domU side with > > for online in /sys/devices/system/cpu/cpu*/online; do > echo 1 > $online > done > > Now we see: > > # xl list 2 > Name ID Mem VCPUs State Time(s) > test 2 15360 4 -b---- 6617.8 > > I''ve added this as a comment to the bugzilla.That is a generic bug - its a race in the generic code where the cpuX directory is created; then udev kicks off and tries to echo 1 > cpuX/online (but online hasn''t been created yet); the cpu-hotplug code creates ''online'' directory. I''ve asked Greg KH about it, and here is his take: https://lkml.org/lkml/2012/4/30/198 But I never got to prep a patch. If somebody gets to do it before me, I owe them a beer!
On Tue, Jun 26, 2012 at 02:09:06PM -0700, Konrad Rzeszutek Wilk wrote:> On Tue, Jun 26, 2012 at 01:31:51PM -0700, Matt Wilson wrote: > > On Tue, Jun 26, 2012 at 01:39:42AM -0700, Ian Campbell wrote: > > > * [BUG] vcpu-set doesn''t take effect on guest, reported by Intel: > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822 > > > > This may be a problem with the guest, rather than a problem with Xen > > or the toolstack. I tested on a domU running a 3.2.20-based Linux > > kernel. The domU kernel didn''t automatically enable the vCPUs after > > calling "xl vcpu-set" to increase the allocation. > > [...] > > > > I''ve added this as a comment to the bugzilla. > > That is a generic bug - its a race in the generic code where > the cpuX directory is created; then udev kicks off and tries to > echo 1 > cpuX/online (but online hasn''t been created yet); the cpu-hotplug > code creates ''online'' directory. > > I''ve asked Greg KH about it, and here is his take: > https://lkml.org/lkml/2012/4/30/198 > > But I never got to prep a patch. If somebody gets to do it before me, > I owe them a beer!My problem was that I didn''t even have a udev rule to auto-online hotplugged CPUs. Everything works as expected after adding the rule suggested on the wiki: http://wiki.xen.org/wiki/Paravirt_Linux_CPU_Hotplug I''m thinking that the bug report is just this well hashed out problem. For historical reference, here''s the thread discussing the behavior change in pv-ops kernels: http://lists.xen.org/archives/html/xen-devel/2010-05/msg00516.html Matt
On Tue, 2012-06-26 at 23:57 +0100, Matt Wilson wrote:> On Tue, Jun 26, 2012 at 02:09:06PM -0700, Konrad Rzeszutek Wilk wrote: > > On Tue, Jun 26, 2012 at 01:31:51PM -0700, Matt Wilson wrote: > > > On Tue, Jun 26, 2012 at 01:39:42AM -0700, Ian Campbell wrote: > > > > * [BUG] vcpu-set doesn''t take effect on guest, reported by Intel: > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822 > > > > > > This may be a problem with the guest, rather than a problem with Xen > > > or the toolstack. I tested on a domU running a 3.2.20-based Linux > > > kernel. The domU kernel didn''t automatically enable the vCPUs after > > > calling "xl vcpu-set" to increase the allocation. > > > [...] > > > > > > I''ve added this as a comment to the bugzilla. > > > > That is a generic bug - its a race in the generic code where > > the cpuX directory is created; then udev kicks off and tries to > > echo 1 > cpuX/online (but online hasn''t been created yet); the cpu-hotplug > > code creates ''online'' directory. > > > > I''ve asked Greg KH about it, and here is his take: > > https://lkml.org/lkml/2012/4/30/198 > > > > But I never got to prep a patch. If somebody gets to do it before me, > > I owe them a beer! > > My problem was that I didn''t even have a udev rule to auto-online > hotplugged CPUs. Everything works as expected after adding the rule > suggested on the wiki: http://wiki.xen.org/wiki/Paravirt_Linux_CPU_Hotplug > > I''m thinking that the bug report is just this well hashed out > problem. For historical reference, here''s the thread discussing the > behavior change in pv-ops kernels: > http://lists.xen.org/archives/html/xen-devel/2010-05/msg00516.htmlI''ve added a link to that thread to the wiki page.
>>> On 26.06.12 at 10:39, Ian Campbell <Ian.Campbell@citrix.com> wrote: > hypervisor, blockers: > > * NoneWe should evaluate whether getting the vMCE interface into a sane state ought to be treated as a blocker (see Jinsong''s recent posting about their design work). Otherwise we''ll run into yet another round of compatibility issues when moving on to 4.3, particularly with respect to migration. Jan
On Wed, 2012-06-27 at 14:12 +0100, Jan Beulich wrote:> >>> On 26.06.12 at 10:39, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > hypervisor, blockers: > > > > * None > > We should evaluate whether getting the vMCE interface into a > sane state ought to be treated as a blocker (see Jinsong''s > recent posting about their design work). Otherwise we''ll run > into yet another round of compatibility issues when moving on > to 4.3, particularly with respect to migration.Isn''t this way to late for 4.2 if it''s only at the design stage right now? Does vMCE exist in Xen unstable today? Did it exist in 4.1? I think we''ll need to just suck it up and accept that migration needs handling for 4.3. Ian.
>>> On 27.06.12 at 16:52, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Wed, 2012-06-27 at 14:12 +0100, Jan Beulich wrote: >> >>> On 26.06.12 at 10:39, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> > hypervisor, blockers: >> > >> > * None >> >> We should evaluate whether getting the vMCE interface into a >> sane state ought to be treated as a blocker (see Jinsong''s >> recent posting about their design work). Otherwise we''ll run >> into yet another round of compatibility issues when moving on >> to 4.3, particularly with respect to migration. > > Isn''t this way to late for 4.2 if it''s only at the design stage right > now?That''s why I''m bringing this up.> Does vMCE exist in Xen unstable today? Did it exist in 4.1?Yes. And what information get migrated is different between 4.1 and 4.2 already.> I think we''ll need to just suck it up and accept that migration needs > handling for 4.3.I was hoping to have at least the HVM save records in 4.2 in a state suitable for 4.3. Jan
On Wed, 2012-06-27 at 15:57 +0100, Jan Beulich wrote:> >>> On 27.06.12 at 16:52, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > On Wed, 2012-06-27 at 14:12 +0100, Jan Beulich wrote: > >> >>> On 26.06.12 at 10:39, Ian Campbell <Ian.Campbell@citrix.com> wrote: > >> > hypervisor, blockers: > >> > > >> > * None > >> > >> We should evaluate whether getting the vMCE interface into a > >> sane state ought to be treated as a blocker (see Jinsong''s > >> recent posting about their design work). Otherwise we''ll run > >> into yet another round of compatibility issues when moving on > >> to 4.3, particularly with respect to migration. > > > > Isn''t this way to late for 4.2 if it''s only at the design stage right > > now? > > That''s why I''m bringing this up. > > > Does vMCE exist in Xen unstable today? Did it exist in 4.1? > > Yes. And what information get migrated is different between > 4.1 and 4.2 already. > > > I think we''ll need to just suck it up and accept that migration needs > > handling for 4.3. > > I was hoping to have at least the HVM save records in 4.2 in a > state suitable for 4.3.That might be reasonable, I guess it depends what that looks like and how much real code impact as opposed to just save record it has? Ian.
>>> On 27.06.12 at 17:01, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Wed, 2012-06-27 at 15:57 +0100, Jan Beulich wrote: >> >>> On 27.06.12 at 16:52, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> > On Wed, 2012-06-27 at 14:12 +0100, Jan Beulich wrote: >> >> >>> On 26.06.12 at 10:39, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> >> > hypervisor, blockers: >> >> > >> >> > * None >> >> >> >> We should evaluate whether getting the vMCE interface into a >> >> sane state ought to be treated as a blocker (see Jinsong''s >> >> recent posting about their design work). Otherwise we''ll run >> >> into yet another round of compatibility issues when moving on >> >> to 4.3, particularly with respect to migration. >> > >> > Isn''t this way to late for 4.2 if it''s only at the design stage right >> > now? >> >> That''s why I''m bringing this up. >> >> > Does vMCE exist in Xen unstable today? Did it exist in 4.1? >> >> Yes. And what information get migrated is different between >> 4.1 and 4.2 already. >> >> > I think we''ll need to just suck it up and accept that migration needs >> > handling for 4.3. >> >> I was hoping to have at least the HVM save records in 4.2 in a >> state suitable for 4.3. > > That might be reasonable, I guess it depends what that looks like and > how much real code impact as opposed to just save record it has?Certainly. Minimally, code handling the expected to be extended save record would need to be added though. In any case, I''d appreciate if you could add this at least to the nice-to-have section. Jan
> -----Original Message----- > From: xen-devel-bounces@lists.xen.org > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Matt Wilson > Sent: Wednesday, June 27, 2012 6:57 AM > To: Konrad Rzeszutek Wilk > Cc: Ian Campbell; xen-devel > Subject: Re: [Xen-devel] Xen 4.2 Release Plan / TODO > > On Tue, Jun 26, 2012 at 02:09:06PM -0700, Konrad Rzeszutek Wilk wrote: > > On Tue, Jun 26, 2012 at 01:31:51PM -0700, Matt Wilson wrote: > > > On Tue, Jun 26, 2012 at 01:39:42AM -0700, Ian Campbell wrote: > > > > * [BUG] vcpu-set doesn''t take effect on guest, reported by Intel: > > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822 > > > > > > This may be a problem with the guest, rather than a problem with Xen > > > or the toolstack. I tested on a domU running a 3.2.20-based Linux > > > kernel. The domU kernel didn''t automatically enable the vCPUs after > > > calling "xl vcpu-set" to increase the allocation. > > > [...] > > > > > > I''ve added this as a comment to the bugzilla. > > > > That is a generic bug - its a race in the generic code where > > the cpuX directory is created; then udev kicks off and tries to > > echo 1 > cpuX/online (but online hasn''t been created yet); the > cpu-hotplug > > code creates ''online'' directory. > > > > I''ve asked Greg KH about it, and here is his take: > > https://lkml.org/lkml/2012/4/30/198 > > > > But I never got to prep a patch. If somebody gets to do it before me, > > I owe them a beer! > > My problem was that I didn''t even have a udev rule to auto-online > hotplugged CPUs. Everything works as expected after adding the rule > suggested on the wiki: > http://wiki.xen.org/wiki/Paravirt_Linux_CPU_Hotplug > > I''m thinking that the bug report is just this well hashed out > problem. For historical reference, here''s the thread discussing the > behavior change in pv-ops kernels: > http://lists.xen.org/archives/html/xen-devel/2010-05/msg00516.html >Hi Matt, thanks for the useful status. According to my testing on xen-unstable(#25517) with linux3.4.3 dom0 and RHEL6.2 hvm guest, ''xl vcpu-set'' can increase the number of the vCPU for guest. But it can''t decrease the number of vCPU. After trying to decrease the number of vCPU, the number of the onlined CPU in /sys/devices/system/cpu/ or /proc/cpuinfo is not changed. But I can do "echo 0 > /sys/devices/system/cpu/cpu3/online" to offline the CPU3 in the guest even if I didn''t use any command line like ''xl vcpu-set''. Also, I can do "echo 1 > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/LNXCPU:03/eject" to remove CPU3 in the guest. Note that ''CPU3'' can be any CPU except for CPU0. Also add a comment in the bugzilla.
At 09:39 +0100 on 26 Jun (1340703582), Ian Campbell wrote:> hypervisor, nice to have: > > * PoD performance improvements (George Dunlap, and reviewed > awaiting repost)Reposted, and applied: DONE. Tim.
Plan for a 4.2 release:
http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
The time line is as follows:
19 March -- TODO list locked down
2 April -- Feature Freeze
<< WE ARE HERE
When It's Ready -- First release candidate
Weekly -- RCN+1 until release
Lots of DONE this week which is good, including one of the big three
remaining issues (libxl_domain_suspend asyncification) has gone in
now. Still to come are Roger's hotplug script changes (which acutally
cover multiple items on the list) and Dario's basic NUMA support, both
of which I think are almost there.
The updated TODO list follows.
If you are aware of any bugs which must/should be fixed for 4.2 then
please reply to this thread (otherwise I may not remember to pick them
up next week)
Per the release plan a strong case will now have to be made as to why
new items should be added to the list, especially as a blocker, rather
than deferred to 4.3.
hypervisor, blockers:
* [BUG] stub domains broken. HVM_PARAM_DM_DOMAIN needs to reset
HVM_PARAM_BUFIOREQ_EVTCHN (Anthony Perard, patch sent, reviewed,
awaiting repost)
tools, blockers:
* libxl stable API -- we would like 4.2 to define a stable API
which downstream's can start to rely on not changing. Aspects of
this are:
* Interfaces which may need to be async:
* libxl_domain_suspend. Move xc_domain_save/restore into a
separate process (Ian Jackson, DONE).
* libxl_device_{disk,nic,vkb,add,pci}_add (and
remove). (Roger Pau Monné, disk & nic included in
calling hotplug scripts from xl, vkb
trivial, not looked at pci yet)
* LIBXL_NIC_TYPE enum names are confusing. (Roger, included in
calling hotplug scripts series)
* use libxl_cpumap for b_info.avail_cpus instead of an int,
this allows setting more than 31 CPUS (Yang Z Zhang, DONE)
* use an enum for VGA interface type (e.g. Cirrus,
StdVGA). Allows for QXL support (in 4.3). (Zhou Peng, DONE)
* xl compatibility with xm:
* [BUG] cannot create an empty CD-ROM drive on HVM guest,
reported by Fabio Fantoni in <4F9672DD.2080902@tiscali.it>
* does not automatically try to select a (set of) node(s) on
which to create a VM and pin its vcpus there. (Dario
Faggioli, posted and reviewed, awaiting a repost)
* [CHECK] More formally deprecate xm/xend. Manpage patches already
in tree. Needs release noting and communication around -rc1 to
remind people to test xl.
* calling hotplug scripts from xl (Linux and NetBSD) (Roger Pau
Monné, waiting on another iteration)
* Block script support -- follows on from hotplug script (Roger
Pau Monné, "just be a matter of removing an "if"")
* Adjustments needed for qdisk backend to work on non-pvops Linux.
"qemu/xendisk: set maximum number of grants to be used" (Jan
Beulich, DONE for both qemu-xen-upstream and
qemu-xen-traditional)
* [CHECK] Confirm that migration from Xen 4.1 -> 4.2 works.
* [BUG] LIBLEAFDIR et al and libfsimage do the wrong thing on
modern Debian/Ubuntu w/ multiarch capabilities (Matt Wilson,
patch posted)
* libxl to reject attempts to migrate a domain using upstream
qemu, due to lack of log dirty support (Ian C, patch sent,
reviewed, awaiting repost)
hypervisor, nice to have:
* PoD performance improvements (George Dunlap, DONE)
* vMCE save/restore changes, to simplify migration 4.2->4.3
(Jinsong Liu)
tools, nice to have:
* xl compatibility with xm:
* Accept "xl cr /dev/null param=value" to provide all config
on the command line (W. Michael Petullo, patch posted)
* libxl stable API
* libxl_wait_for_free_memory/libxl_wait_for_memory_target.
Interface needs an overhaul, related to
locking/serialization over domain create. IanJ to add note
about this interface being substandard but otherwise defer
to 4.3.
* Interfaces which may need to be async:
* libxl_cdrom_insert. Should be easy once
disk_{add,remove} done. This is basically a helper
function and its functionality can be implemented in
terms of the libxl_disk_* interfaces. If this is not
done in time we should document as a substandard
interface which is subject to change post 4.2.
* xl.cfg(5) documentation patch for qemu-upstream
videoram/videomem support:
http://lists.xen.org/archives/html/xen-devel/2012-05/msg00250.html
qemu-upstream doesn't support specifying videomem size for the
HVM guest cirrus/stdvga. (but this works with
qemu-xen-traditional). (Pasi Kärkkäinen)
* [BUG] long stop during the guest boot process with qcow image,
reported by Intel: http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821
* [BUG] vcpu-set doesn't take effect on guest, reported by Intel:
http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
* Load blktap driver from xencommons initscript if available, thread at:
<db614e92faf743e20b3f.1337096977@kodo2>. To be fixed more
properly in 4.3. (Patch posted, discussion, plan to take simple
xencommons patch for 4.2 and revist for 4.3)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 02.07.12 at 13:02, Ian Campbell <Ian.Campbell@citrix.com> wrote: > hypervisor, blockers: > > * [BUG] stub domains broken. HVM_PARAM_DM_DOMAIN needs to reset > HVM_PARAM_BUFIOREQ_EVTCHN (Anthony Perard, patch sent, reviewed, > awaiting repost)Committed (with minor adjustments, but Anthony, please double check). Jan
On Tue, Jul 3, 2012 at 8:52 AM, Jan Beulich <JBeulich@suse.com> wrote:>>>> On 02.07.12 at 13:02, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> hypervisor, blockers: >> >> * [BUG] stub domains broken. HVM_PARAM_DM_DOMAIN needs to reset >> HVM_PARAM_BUFIOREQ_EVTCHN (Anthony Perard, patch sent, reviewed, >> awaiting repost) > > Committed (with minor adjustments, but Anthony, please double > check).Look good to me. Thanks. -- Anthony PERARD
On Mon, 2012-07-02 at 12:02 +0100, Ian Campbell wrote:> tools, blockers: > > [...] > > * xl compatibility with xm: > > * [BUG] cannot create an empty CD-ROM drive on HVM guest, > reported by Fabio Fantoni in <4F9672DD.2080902@tiscali.it> > > * does not automatically try to select a (set of) node(s) on > which to create a VM and pin its vcpus there. (Dario > Faggioli, posted and reviewed, awaiting a repost) >Just reposted, awaiting review. Thanks and Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Ian Campbell wrote:> Plan for a 4.2 release: > http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html > > The time line is as follows: > > 19 March -- TODO list locked down > 2 April -- Feature Freeze > << WE ARE HERE > When It's Ready -- First release candidate > Weekly -- RCN+1 until release > > Lots of DONE this week which is good, including one of the big three > remaining issues (libxl_domain_suspend asyncification) has gone in > now. Still to come are Roger's hotplug script changes (which acutally > cover multiple items on the list) and Dario's basic NUMA support, both > of which I think are almost there. > > The updated TODO list follows. > > If you are aware of any bugs which must/should be fixed for 4.2 then > please reply to this thread (otherwise I may not remember to pick them > up next week) > > Per the release plan a strong case will now have to be made as to why > new items should be added to the list, especially as a blocker, rather > than deferred to 4.3. > > hypervisor, blockers: > > * [BUG] stub domains broken. HVM_PARAM_DM_DOMAIN needs to reset > HVM_PARAM_BUFIOREQ_EVTCHN (Anthony Perard, patch sent, reviewed, > awaiting repost) > > tools, blockers: > > * libxl stable API -- we would like 4.2 to define a stable API > which downstream's can start to rely on not changing. Aspects of > this are: > > * Interfaces which may need to be async: > > * libxl_domain_suspend. Move xc_domain_save/restore into a > separate process (Ian Jackson, DONE). > > * libxl_device_{disk,nic,vkb,add,pci}_add (and > remove). (Roger Pau Monné, disk& nic included in > calling hotplug scripts from xl, vkb > trivial, not looked at pci yet) > > * LIBXL_NIC_TYPE enum names are confusing. (Roger, included in > calling hotplug scripts series) > > * use libxl_cpumap for b_info.avail_cpus instead of an int, > this allows setting more than 31 CPUS (Yang Z Zhang, DONE) > > * use an enum for VGA interface type (e.g. Cirrus, > StdVGA). Allows for QXL support (in 4.3). (Zhou Peng, DONE) > > * xl compatibility with xm: > > * [BUG] cannot create an empty CD-ROM drive on HVM guest, > reported by Fabio Fantoni in<4F9672DD.2080902@tiscali.it> > > * does not automatically try to select a (set of) node(s) on > which to create a VM and pin its vcpus there. (Dario > Faggioli, posted and reviewed, awaiting a repost) > > * [CHECK] More formally deprecate xm/xend. Manpage patches already > in tree. Needs release noting and communication around -rc1 to > remind people to test xl. > > * calling hotplug scripts from xl (Linux and NetBSD) (Roger Pau > Monné, waiting on another iteration)Posted v8.> > * Block script support -- follows on from hotplug script (Roger > Pau Monné, "just be a matter of removing an "if"") > > * Adjustments needed for qdisk backend to work on non-pvops Linux. > "qemu/xendisk: set maximum number of grants to be used" (Jan > Beulich, DONE for both qemu-xen-upstream and > qemu-xen-traditional) > > * [CHECK] Confirm that migration from Xen 4.1 -> 4.2 works. > > * [BUG] LIBLEAFDIR et al and libfsimage do the wrong thing on > modern Debian/Ubuntu w/ multiarch capabilities (Matt Wilson, > patch posted) > > * libxl to reject attempts to migrate a domain using upstream > qemu, due to lack of log dirty support (Ian C, patch sent, > reviewed, awaiting repost) > > hypervisor, nice to have: > > * PoD performance improvements (George Dunlap, DONE) > > * vMCE save/restore changes, to simplify migration 4.2->4.3 > (Jinsong Liu) > > tools, nice to have: > > * xl compatibility with xm: > > * Accept "xl cr /dev/null param=value" to provide all config > on the command line (W. Michael Petullo, patch posted) > > * libxl stable API > > * libxl_wait_for_free_memory/libxl_wait_for_memory_target. > Interface needs an overhaul, related to > locking/serialization over domain create. IanJ to add note > about this interface being substandard but otherwise defer > to 4.3. > > * Interfaces which may need to be async: > > * libxl_cdrom_insert. Should be easy once > disk_{add,remove} done. This is basically a helper > function and its functionality can be implemented in > terms of the libxl_disk_* interfaces. If this is not > done in time we should document as a substandard > interface which is subject to change post 4.2. > > * xl.cfg(5) documentation patch for qemu-upstream > videoram/videomem support: > http://lists.xen.org/archives/html/xen-devel/2012-05/msg00250.html > qemu-upstream doesn't support specifying videomem size for the > HVM guest cirrus/stdvga. (but this works with > qemu-xen-traditional). (Pasi Kärkkäinen) > > * [BUG] long stop during the guest boot process with qcow image, > reported by Intel: http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821 > > * [BUG] vcpu-set doesn't take effect on guest, reported by Intel: > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822 > > * Load blktap driver from xencommons initscript if available, thread at: > <db614e92faf743e20b3f.1337096977@kodo2>. To be fixed more > properly in 4.3. (Patch posted, discussion, plan to take simple > xencommons patch for 4.2 and revist for 4.3) > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Roger Pau Monne wrote:> Ian Campbell wrote: >> Plan for a 4.2 release: >> http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html >> >> The time line is as follows: >> >> 19 March -- TODO list locked down >> 2 April -- Feature Freeze >> << WE ARE HERE >> When It's Ready -- First release candidate >> Weekly -- RCN+1 until release >> >> Lots of DONE this week which is good, including one of the big three >> remaining issues (libxl_domain_suspend asyncification) has gone in >> now. Still to come are Roger's hotplug script changes (which acutally >> cover multiple items on the list) and Dario's basic NUMA support, both >> of which I think are almost there. >> >> The updated TODO list follows. >> >> If you are aware of any bugs which must/should be fixed for 4.2 then >> please reply to this thread (otherwise I may not remember to pick them >> up next week) >> >> Per the release plan a strong case will now have to be made as to why >> new items should be added to the list, especially as a blocker, rather >> than deferred to 4.3. >> >> hypervisor, blockers: >> >> * [BUG] stub domains broken. HVM_PARAM_DM_DOMAIN needs to reset >> HVM_PARAM_BUFIOREQ_EVTCHN (Anthony Perard, patch sent, reviewed, >> awaiting repost) >> >> tools, blockers: >> >> * libxl stable API -- we would like 4.2 to define a stable API >> which downstream's can start to rely on not changing. Aspects of >> this are: >> >> * Interfaces which may need to be async: >> >> * libxl_domain_suspend. Move xc_domain_save/restore into a >> separate process (Ian Jackson, DONE). >> >> * libxl_device_{disk,nic,vkb,add,pci}_add (and >> remove). (Roger Pau Monné, disk& nic included in >> calling hotplug scripts from xl, vkb >> trivial, not looked at pci yet)vkb and vfvb posted as part of my v9 hotplug series. I've given a quick look at PCI and it looks tricky, but I think some parts of the code are no longer needed (mainly the wait for the device model, because we already know Qemu is up and running when we attach PCI devices now), so it should simplify the conversion a bit.>> >> * LIBXL_NIC_TYPE enum names are confusing. (Roger, included in >> calling hotplug scripts series) >> >> * use libxl_cpumap for b_info.avail_cpus instead of an int, >> this allows setting more than 31 CPUS (Yang Z Zhang, DONE) >> >> * use an enum for VGA interface type (e.g. Cirrus, >> StdVGA). Allows for QXL support (in 4.3). (Zhou Peng, DONE) >> >> * xl compatibility with xm: >> >> * [BUG] cannot create an empty CD-ROM drive on HVM guest, >> reported by Fabio Fantoni in<4F9672DD.2080902@tiscali.it> >> >> * does not automatically try to select a (set of) node(s) on >> which to create a VM and pin its vcpus there. (Dario >> Faggioli, posted and reviewed, awaiting a repost) >> >> * [CHECK] More formally deprecate xm/xend. Manpage patches already >> in tree. Needs release noting and communication around -rc1 to >> remind people to test xl. >> >> * calling hotplug scripts from xl (Linux and NetBSD) (Roger Pau >> Monné, waiting on another iteration) > > Posted v8.v9 now.> >> * Block script support -- follows on from hotplug script (Roger >> Pau Monné, "just be a matter of removing an "if"") >> >> * Adjustments needed for qdisk backend to work on non-pvops Linux. >> "qemu/xendisk: set maximum number of grants to be used" (Jan >> Beulich, DONE for both qemu-xen-upstream and >> qemu-xen-traditional) >> >> * [CHECK] Confirm that migration from Xen 4.1 -> 4.2 works. >> >> * [BUG] LIBLEAFDIR et al and libfsimage do the wrong thing on >> modern Debian/Ubuntu w/ multiarch capabilities (Matt Wilson, >> patch posted) >> >> * libxl to reject attempts to migrate a domain using upstream >> qemu, due to lack of log dirty support (Ian C, patch sent, >> reviewed, awaiting repost) >> >> hypervisor, nice to have: >> >> * PoD performance improvements (George Dunlap, DONE) >> >> * vMCE save/restore changes, to simplify migration 4.2->4.3 >> (Jinsong Liu) >> >> tools, nice to have: >> >> * xl compatibility with xm: >> >> * Accept "xl cr /dev/null param=value" to provide all config >> on the command line (W. Michael Petullo, patch posted) >> >> * libxl stable API >> >> * libxl_wait_for_free_memory/libxl_wait_for_memory_target. >> Interface needs an overhaul, related to >> locking/serialization over domain create. IanJ to add note >> about this interface being substandard but otherwise defer >> to 4.3. >> >> * Interfaces which may need to be async: >> >> * libxl_cdrom_insert. Should be easy once >> disk_{add,remove} done. This is basically a helper >> function and its functionality can be implemented in >> terms of the libxl_disk_* interfaces. If this is not >> done in time we should document as a substandard >> interface which is subject to change post 4.2. >> >> * xl.cfg(5) documentation patch for qemu-upstream >> videoram/videomem support: >> http://lists.xen.org/archives/html/xen-devel/2012-05/msg00250.html >> qemu-upstream doesn't support specifying videomem size for the >> HVM guest cirrus/stdvga. (but this works with >> qemu-xen-traditional). (Pasi Kärkkäinen) >> >> * [BUG] long stop during the guest boot process with qcow image, >> reported by Intel: http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821 >> >> * [BUG] vcpu-set doesn't take effect on guest, reported by Intel: >> http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822 >> >> * Load blktap driver from xencommons initscript if available, thread at: >> <db614e92faf743e20b3f.1337096977@kodo2>. To be fixed more >> properly in 4.3. (Patch posted, discussion, plan to take simple >> xencommons patch for 4.2 and revist for 4.3) >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel