Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
Thank you, Wei. On 5/5/2015 5:12 PM, Wei Liu wrote: On Mon, May 04, 2015 at 08:51:56PM +0800, Yu, Zhang wrote: Hi Wei, Thanks for your reply. On 5/4/2015 5:44 PM, Wei Liu wrote: (Thanks for trimming the CC list before hand) On Mon, May 04, 2015 at 02:05:49PM +0800, Yu, Zhang wrote: Hi Wei, Hello. This is Zhang Yu from Intel graphic virtualization team. Previously in Xen hackathon, Paul and I mentioned that there're several patch series for XenGT that need to be tracked on Xen 4.6. Here, I'd like to confirm with you about these patchsets: 1 16-byte MMIO emulation fix – owned by Paul; Could you explain a bit why this is needed? AIUI it's just a latent bug that discovered by this particular usecase, right? In other words, not really a regression introduced by ioreq server. OK. Then we will fix this, but not necessary to track this bug. IIRC, this is not a regression. Am I right, Paul? :-) 2 Ioreq server refactor – owned by Yu; 3 The PV IOMMU – owned by Malcolm; This one may not be completed in Xen 4.6, but a basic feature(to return a BFN which equals the MFN when IOMMU is 1:1 mapped or is disabled), might be necessary in this release. So could we also add separate tracks for these patches(I noticed the 3rd is already mentioned in your mail)? :-) I tend to track only big feature items. Non-blocking bugs and small refactoring are not tracked. Well, by big feature, I'm not sure if this ioreq server refactor issue qualifies this definition. :-) But this is part of the functionalities that support the Intel GVT-g solution, which is a big feature from the overall POV. However, if we track the Intel GVT-g feature as a whole new feature, the patch series would seem too scattered. As I understand it, Intel GVT-g consists of different components. Xen component is only one of many components that float around. I can try to setup a Xen GVT-g item and put this under a subitem if it makes sense. Yes. So if convenient, how about setup a Intel GVT-g item and put the ioreq server patch series as a subitem in 4.6? Sorry for being unfamiliar with the Xen development schedules, but is there any approach we can track ioreq server refactor patches(my mission is to upstream this in Xen 4.6)? :-) I think this sort of thing happens when it happens. You just need to follow the usual development process. Note that we need not wait until everything in this list go in before we can release 4.6. Tracking them here is more about having an idea what exciting things are going on within Xen community. Got it, and thank you! :-) Wei. The first one needs to be actively tracked if it's a regression. I already track the third one since it's a big feature. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel Thanks Yu ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel B.R. Yu ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
On Mon, May 04, 2015 at 08:51:56PM +0800, Yu, Zhang wrote: Hi Wei, Thanks for your reply. On 5/4/2015 5:44 PM, Wei Liu wrote: (Thanks for trimming the CC list before hand) On Mon, May 04, 2015 at 02:05:49PM +0800, Yu, Zhang wrote: Hi Wei, Hello. This is Zhang Yu from Intel graphic virtualization team. Previously in Xen hackathon, Paul and I mentioned that there're several patch series for XenGT that need to be tracked on Xen 4.6. Here, I'd like to confirm with you about these patchsets: 1 16-byte MMIO emulation fix – owned by Paul; Could you explain a bit why this is needed? AIUI it's just a latent bug that discovered by this particular usecase, right? In other words, not really a regression introduced by ioreq server. OK. Then we will fix this, but not necessary to track this bug. IIRC, this is not a regression. Am I right, Paul? :-) 2 Ioreq server refactor – owned by Yu; 3 The PV IOMMU – owned by Malcolm; This one may not be completed in Xen 4.6, but a basic feature(to return a BFN which equals the MFN when IOMMU is 1:1 mapped or is disabled), might be necessary in this release. So could we also add separate tracks for these patches(I noticed the 3rd is already mentioned in your mail)? :-) I tend to track only big feature items. Non-blocking bugs and small refactoring are not tracked. Well, by big feature, I'm not sure if this ioreq server refactor issue qualifies this definition. :-) But this is part of the functionalities that support the Intel GVT-g solution, which is a big feature from the overall POV. However, if we track the Intel GVT-g feature as a whole new feature, the patch series would seem too scattered. As I understand it, Intel GVT-g consists of different components. Xen component is only one of many components that float around. I can try to setup a Xen GVT-g item and put this under a subitem if it makes sense. Sorry for being unfamiliar with the Xen development schedules, but is there any approach we can track ioreq server refactor patches(my mission is to upstream this in Xen 4.6)? :-) I think this sort of thing happens when it happens. You just need to follow the usual development process. Note that we need not wait until everything in this list go in before we can release 4.6. Tracking them here is more about having an idea what exciting things are going on within Xen community. Wei. The first one needs to be actively tracked if it's a regression. I already track the third one since it's a big feature. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel Thanks Yu ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
Hi Wei, This is Zhang Yu from Intel graphic virtualization team. Previously in Xen hackathon, Paul and I mentioned that there're several patch series for XenGT that need to be tracked on Xen 4.6. Here, I'd like to confirm with you about these patchsets: 1 16-byte MMIO emulation fix – owned by Paul; 2 Ioreq server refactor – owned by Yu; 3 The PV IOMMU – owned by Malcolm; This one may not be completed in Xen 4.6, but a basic feature(to return a BFN which equals the MFN when IOMMU is 1:1 mapped or is disabled), might be necessary in this release. So could we also add separate tracks for these patches(I noticed the 3rd is already mentioned in your mail)? :-) Thanks Yu On 4/14/2015 6:27 PM, wei.l...@citrix.com wrote: Hi all We are now three months into 4.6 development window. This is an email to keep track of all the patch series I gathered. It is by no means complete and / or acurate. Feel free to reply this email with new projects or correct my misunderstanding. = Timeline = We are planning on a 9-month release cycle, but we could also release a bit earlier if everything goes well (no blocker, no critical bug). * Development start: 6 Jan 2015 === We are here === * Feature Freeze: 10 Jul 2015 * RCs: TBD * Release Date: 9 Oct 2015 (could release earlier) The RCs and release will of course depend on stability and bugs, and will therefore be fairly unpredictable. Bug-fixes, if Acked-by by maintainer, can go anytime before the First RC. Later on we will need to figure out the risk of regression/reward to eliminate the possiblity of a bug introducing another bug. = Prognosis = The states are: none - fair - ok - good - done none - nothing yet fair - still working on it, patches are prototypes or RFC ok - patches posted, acting on review good - some last minute pieces done - all done, might have bugs = Bug Fixes = Bug fixes can be checked in without a freeze exception throughout the freeze, unless the maintainer thinks they are particularly high risk. In later RC's, we may even begin rejecting bug fixes if the broken functionality is small and the risk to other functionality is high. Document changes can go in anytime if the maintainer is OK with it. These are guidelines and principles to give you an idea where we're coming from; if you think there's a good reason why making an exception for you will help us make Xen better than not doing so, feel free to make your case. == Hypervisor == * Alternate p2m: support multiple copies of host p2m (ok) - Ed White * Improve RTDS scheduler (none) - Dagaen Golomb, Meng Xu * Credit2: introduce per-vcpu hard and soft affinity (good) - Justin T. Weaver * sndif: add API for para-virtual sound (fair) v7 posted - Oleksandr Dmytryshyn * gnttab: improve scalability (good) v5 posted - Christoph Egger * Display IO topology when PXM data is available (good) v3 posted - Boris Ostrovsky * Xen multiboot2-EFI support (fair) See http://lists.xen.org/archives/html/xen-devel/2013-05/msg02281.html RFC posted - Daniel Kiper * Credit2 production ready (none) cpu pinning, numa affinity and cpu reservation - George Dunlap * VM event patches (none) Add support for XSETBV vm_events, Support hybernating guests Support for VMCALL-based vm_events - Razvan Cojocaru === Hypervisor X86 === * Intel Cache Allocation Technology (good) - Chao Peng * VT-d Posted-interrupt (PI) (none) - Wu, Feng * HT enabled with credit has 7.9 per perf drop. (none) kernbench demonstrated it http://www.gossamer-threads.com/lists/xen/devel/339409 This has existed since credit1 introduction. - Dario Faggioli * Support controlling the max C-state sub-state (fair) v3 posted Hadn't see the patch reposted. - Ross Lagerwall * IOMMU ABI for guests to map their DMA regions (fair) - Malcolm Crossley * Intel PML (Page Modification Logging) for Xen (none) design doc posted - Kai Huang * RMRR fix (fair) RFC posted - Tiejun Chen * VPMU - 'perf' support in Xen (good) v14 posted Need reviews/final ack. - Boris Ostrovsky * PVH - AMD hardware support. (fair) RFC posted - Elena Ufimtseva * PVH dom0 (fair) RFC posted - Elena Ufimtseva === Hypervisor ARM === * Mem_access for ARM (good) v13 posted - Tamas K Lengyel * ITS support (fair ) - Vijaya Kumar K * Add ACPI support for arm64 on Xen (fair) RFC posted - Parth Dixit * ARM: reenable support 32-bit userspace running in 64-bit guest (good) v2 posted - Ian Campbell * ARM remote processor iommu module (GPUs + IPUs) (fair) v3 posted - Andrii Tseglytskyi * ARM VM save/restore/live migration (none) Need to rebased against migrationv2 - no code posted. - None * ARM GICv2m support (none) - Suravee Suthikulanit * ARM - passthrough of non-PCI (ok) - Julien Grall * ARM PCI passthrough (none) - Manish
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
(Thanks for trimming the CC list before hand) On Mon, May 04, 2015 at 02:05:49PM +0800, Yu, Zhang wrote: Hi Wei, Hello. This is Zhang Yu from Intel graphic virtualization team. Previously in Xen hackathon, Paul and I mentioned that there're several patch series for XenGT that need to be tracked on Xen 4.6. Here, I'd like to confirm with you about these patchsets: 1 16-byte MMIO emulation fix – owned by Paul; Could you explain a bit why this is needed? AIUI it's just a latent bug that discovered by this particular usecase, right? In other words, not really a regression introduced by ioreq server. 2 Ioreq server refactor – owned by Yu; 3 The PV IOMMU – owned by Malcolm; This one may not be completed in Xen 4.6, but a basic feature(to return a BFN which equals the MFN when IOMMU is 1:1 mapped or is disabled), might be necessary in this release. So could we also add separate tracks for these patches(I noticed the 3rd is already mentioned in your mail)? :-) I tend to track only big feature items. Non-blocking bugs and small refactoring are not tracked. The first one needs to be actively tracked if it's a regression. I already track the third one since it's a big feature. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
Hi Fabio Discussion on a particular bug should be in a separate thread. This thread is mainly for Xen 4.6 release. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
Hi Wei, Thanks for your reply. On 5/4/2015 5:44 PM, Wei Liu wrote: (Thanks for trimming the CC list before hand) On Mon, May 04, 2015 at 02:05:49PM +0800, Yu, Zhang wrote: Hi Wei, Hello. This is Zhang Yu from Intel graphic virtualization team. Previously in Xen hackathon, Paul and I mentioned that there're several patch series for XenGT that need to be tracked on Xen 4.6. Here, I'd like to confirm with you about these patchsets: 1 16-byte MMIO emulation fix – owned by Paul; Could you explain a bit why this is needed? AIUI it's just a latent bug that discovered by this particular usecase, right? In other words, not really a regression introduced by ioreq server. OK. Then we will fix this, but not necessary to track this bug. IIRC, this is not a regression. Am I right, Paul? :-) 2 Ioreq server refactor – owned by Yu; 3 The PV IOMMU – owned by Malcolm; This one may not be completed in Xen 4.6, but a basic feature(to return a BFN which equals the MFN when IOMMU is 1:1 mapped or is disabled), might be necessary in this release. So could we also add separate tracks for these patches(I noticed the 3rd is already mentioned in your mail)? :-) I tend to track only big feature items. Non-blocking bugs and small refactoring are not tracked. Well, by big feature, I'm not sure if this ioreq server refactor issue qualifies this definition. :-) But this is part of the functionalities that support the Intel GVT-g solution, which is a big feature from the overall POV. However, if we track the Intel GVT-g feature as a whole new feature, the patch series would seem too scattered. Sorry for being unfamiliar with the Xen development schedules, but is there any approach we can track ioreq server refactor patches(my mission is to upstream this in Xen 4.6)? :-) The first one needs to be actively tracked if it's a regression. I already track the third one since it's a big feature. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel Thanks Yu ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
Fabio Fantoni wrote: 2015-04-30 18:55 GMT+02:00 Jim Fehlig jfeh...@suse.com mailto:jfeh...@suse.com: Fabio Fantoni wrote: Il 29/04/2015 18:39, Jim Fehlig ha scritto: linux-tyb8:~/ # dmesg | grep -i qxl [4.901158] [drm] qxl: 16M of VRAM memory size [4.901159] [drm] qxl: 63M of IO pages memory ready (VRAM domain) [4.951545] fb: switching to qxldrmfb from VESA VGA [4.951702] fbcon: qxldrmfb (fb0) is primary device [4.976292] qxl :00:04.0: fb0: qxldrmfb frame buffer device [4.976293] qxl :00:04.0: registered panic notifier [4.976296] [drm] Initialized qxl 0.1.0 20120117 for :00:04.0 on minor 0 linux-tyb8:~/ # hwinfo --gfxcard 16: PCI 04.0: 0300 VGA compatible controller (VGA) [Created at pci.328] Unique ID: 8otl.q8E9rb_JDj6 SysFS ID: /devices/pci:00/:00:04.0 SysFS BusID: :00:04.0 Hardware Class: graphics card Model: Red Hat VGA compatible controller Vendor: pci 0x1b36 Red Hat, Inc. Device: pci 0x0100 SubVendor: pci 0x1af4 Red Hat, Inc SubDevice: pci 0x1100 Revision: 0x04 Driver: qxl Driver Modules: drm Memory Range: 0xf000-0xf3ff (rw,non-prefetchable) Memory Range: 0xf400-0xf7ff (rw,non-prefetchable) Memory Range: 0xf905-0xf9051fff (rw,non-prefetchable) I/O Ports: 0xc240-0xc25f (rw) Memory Range: 0xf904-0xf904 (ro,non-prefetchable,disabled) IRQ: 32 (150 events) I/O Ports: 0x3c0-0x3df (rw) Module Alias: pci:v1B36d0100sv1AF4sd1100bc03sc00i00 Driver Info #0: Driver Status: qxl is active Driver Activation Cmd: modprobe qxl Config Status: cfg=new, avail=yes, need=no, active=unknown Primary display adapter: #16 With driver installed should always fails with error similar a what I reported FWIK. I mean this: http://lists.xen.org/archives/html/xen-devel/2015-04/txtGtntonxpzb.txt http://lists.xen.org/archives/html/xen-devel/2015-04/msg03064.html I'm not seeing that. Or you have domU with qxl driver installed, used and working? In this case we must find solution or workaround present in SLES12 and apply it also upstream if missed. The base system is SLES12, but Xen and the tools (including qemu) are fairly recent xen-unstable. So the only thing SLES12 specific would be domU kernel and qxl driver. Thanks for your reply. As you told the more probable fix/workaround can be in dom0's kernel and/or domU's kernel or qxl driver. I tried to search about qxl suse package 0.1.0 repository (saw version in your message) but I not understand exactly what repository see. Jan, or perhaps Olaf or Juergen, might know of a SLES12 kernel change that allows qxl to work. About kernel I found this for patches added in suse: https://github.com/openSUSE/kernel-source/tree/SLE12-SP1 Is it correct? With a fast look I not found patches related FWIK (but I had low knowledge) Next week probably I'll try to restrict the search field trying suse domU in same dom0 I used (wheezy with kernel from backports and other packages update manually), I can try latest opensuse or is better try a SLED12 trial instead? About xen I take a look here: https://build.opensuse.org/package/show/Virtualization/xen I found one patch probably related: https://build.opensuse.org/package/view_file/Virtualization/xen/stdvga-cache.patch?expand=1 you used it in your test? No. I saw also that there is a patch anymore needed: https://build.opensuse.org/package/view_file/Virtualization/xen/qemu-xen-enable-spice-support.patch?expand=1 Yes, agreed... Since this: http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=9aa2cef51f3dced396a5ae10de586206956f9ffd is possible to use configure instead: ./configure --with-extra-qemuu-configure-args=--enable-spice --enable-usb-redir ...for Xen releases containing this commit. Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
2015-04-30 18:55 GMT+02:00 Jim Fehlig jfeh...@suse.com: Fabio Fantoni wrote: Il 29/04/2015 18:39, Jim Fehlig ha scritto: dom0 and domU are both SLES12. Xen is fairly recent xen-unstable plus a few libxl patches. Regards, Jim But the domU was without qxl driver installed? No, it was installed: linux-tyb8:~/ # dmesg | grep -i qxl [4.901158] [drm] qxl: 16M of VRAM memory size [4.901159] [drm] qxl: 63M of IO pages memory ready (VRAM domain) [4.951545] fb: switching to qxldrmfb from VESA VGA [4.951702] fbcon: qxldrmfb (fb0) is primary device [4.976292] qxl :00:04.0: fb0: qxldrmfb frame buffer device [4.976293] qxl :00:04.0: registered panic notifier [4.976296] [drm] Initialized qxl 0.1.0 20120117 for :00:04.0 on minor 0 linux-tyb8:~/ # hwinfo --gfxcard 16: PCI 04.0: 0300 VGA compatible controller (VGA) [Created at pci.328] Unique ID: 8otl.q8E9rb_JDj6 SysFS ID: /devices/pci:00/:00:04.0 SysFS BusID: :00:04.0 Hardware Class: graphics card Model: Red Hat VGA compatible controller Vendor: pci 0x1b36 Red Hat, Inc. Device: pci 0x0100 SubVendor: pci 0x1af4 Red Hat, Inc SubDevice: pci 0x1100 Revision: 0x04 Driver: qxl Driver Modules: drm Memory Range: 0xf000-0xf3ff (rw,non-prefetchable) Memory Range: 0xf400-0xf7ff (rw,non-prefetchable) Memory Range: 0xf905-0xf9051fff (rw,non-prefetchable) I/O Ports: 0xc240-0xc25f (rw) Memory Range: 0xf904-0xf904 (ro,non-prefetchable,disabled) IRQ: 32 (150 events) I/O Ports: 0x3c0-0x3df (rw) Module Alias: pci:v1B36d0100sv1AF4sd1100bc03sc00i00 Driver Info #0: Driver Status: qxl is active Driver Activation Cmd: modprobe qxl Config Status: cfg=new, avail=yes, need=no, active=unknown Primary display adapter: #16 With driver installed should always fails with error similar a what I reported FWIK. I mean this: http://lists.xen.org/archives/html/xen-devel/2015-04/txtGtntonxpzb.txt http://lists.xen.org/archives/html/xen-devel/2015-04/msg03064.html I'm not seeing that. Or you have domU with qxl driver installed, used and working? In this case we must find solution or workaround present in SLES12 and apply it also upstream if missed. The base system is SLES12, but Xen and the tools (including qemu) are fairly recent xen-unstable. So the only thing SLES12 specific would be domU kernel and qxl driver. Regards, Jim Thanks for your reply. As you told the more probable fix/workaround can be in dom0's kernel and/or domU's kernel or qxl driver. I tried to search about qxl suse package 0.1.0 repository (saw version in your message) but I not understand exactly what repository see. About kernel I found this for patches added in suse: https://github.com/openSUSE/kernel-source/tree/SLE12-SP1 Is it correct? With a fast look I not found patches related FWIK (but I had low knowledge) Next week probably I'll try to restrict the search field trying suse domU in same dom0 I used (wheezy with kernel from backports and other packages update manually), I can try latest opensuse or is better try a SLED12 trial instead? About xen I take a look here: https://build.opensuse.org/package/show/Virtualization/xen I found one patch probably related: https://build.opensuse.org/package/view_file/Virtualization/xen/stdvga-cache.patch?expand=1 you used it in your test? I saw also that there is a patch anymore needed: https://build.opensuse.org/package/view_file/Virtualization/xen/qemu-xen-enable-spice-support.patch?expand=1 Since this: http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=9aa2cef51f3dced396a5ae10de586206956f9ffd is possible to use configure instead: ./configure --with-extra-qemuu-configure-args=--enable-spice --enable-usb-redir ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
Il 29/04/2015 18:39, Jim Fehlig ha scritto: Fabio Fantoni wrote: Il 29/04/2015 02:21, Andrew Cooper ha scritto: On 28/04/15 23:17, Jim Fehlig wrote: Jim Fehlig wrote: wei.l...@citrix.com wrote: Hi all We are now three months into 4.6 development window. This is an email to keep track of all the patch series I gathered. It is by no means complete and / or acurate. Feel free to reply this email with new projects or correct my misunderstanding. [...] * libxl: add qxl vga interface support for upstream qemu (fair) - Fabio Fantoni I've been working on SPICE support in the libvirt libxl driver and quickly came across the lack of support for qxl device. What is the status of this work? AFAICT, there was a v16 posted nearly a year ago with no comments http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html After playing with this more, I think the patch will need a LIBXL_HAVE_QXL or similar in libxl.h. I noticed this work was committed in the 4.3 dev cycle, but was reverted before the release by commit 5479961a, which describes problems with instructions that cannot be used for MMIO. Has any progress been made on that front? Is Fabio's patch the only piece missing to support qxl devices? I've tried Fabio's patch on top of fairly recent xen-unstable and don't see the issues mentioned in the commit message of 5479961a. Note that I only tried linux HVM guests though. qxl vga is working good on windows domUs except problem after save/restore on linux domUs instead I wasn't able to get it working today I tried with fedora 22 (beta3) lxde live dvd (have included latest qxl drivers available): with both stdvga and qxl mouse is working but not visible and I not understand why, I'll try also lubuntu 15.04. can you tell me what dom0 and domU have you use for test please? dom0 and domU are both SLES12. Xen is fairly recent xen-unstable plus a few libxl patches. Regards, Jim But the domU was without qxl driver installed? With driver installed should always fails with error similar a what I reported FWIK. I mean this: http://lists.xen.org/archives/html/xen-devel/2015-04/txtGtntonxpzb.txt http://lists.xen.org/archives/html/xen-devel/2015-04/msg03064.html Or you have domU with qxl driver installed, used and working? In this case we must find solution or workaround present in SLES12 and apply it also upstream if missed. Thanks for any reply and sorry for my bad english. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
Fabio Fantoni wrote: Il 29/04/2015 18:39, Jim Fehlig ha scritto: dom0 and domU are both SLES12. Xen is fairly recent xen-unstable plus a few libxl patches. Regards, Jim But the domU was without qxl driver installed? No, it was installed: linux-tyb8:~/ # dmesg | grep -i qxl [4.901158] [drm] qxl: 16M of VRAM memory size [4.901159] [drm] qxl: 63M of IO pages memory ready (VRAM domain) [4.951545] fb: switching to qxldrmfb from VESA VGA [4.951702] fbcon: qxldrmfb (fb0) is primary device [4.976292] qxl :00:04.0: fb0: qxldrmfb frame buffer device [4.976293] qxl :00:04.0: registered panic notifier [4.976296] [drm] Initialized qxl 0.1.0 20120117 for :00:04.0 on minor 0 linux-tyb8:~/ # hwinfo --gfxcard 16: PCI 04.0: 0300 VGA compatible controller (VGA) [Created at pci.328] Unique ID: 8otl.q8E9rb_JDj6 SysFS ID: /devices/pci:00/:00:04.0 SysFS BusID: :00:04.0 Hardware Class: graphics card Model: Red Hat VGA compatible controller Vendor: pci 0x1b36 Red Hat, Inc. Device: pci 0x0100 SubVendor: pci 0x1af4 Red Hat, Inc SubDevice: pci 0x1100 Revision: 0x04 Driver: qxl Driver Modules: drm Memory Range: 0xf000-0xf3ff (rw,non-prefetchable) Memory Range: 0xf400-0xf7ff (rw,non-prefetchable) Memory Range: 0xf905-0xf9051fff (rw,non-prefetchable) I/O Ports: 0xc240-0xc25f (rw) Memory Range: 0xf904-0xf904 (ro,non-prefetchable,disabled) IRQ: 32 (150 events) I/O Ports: 0x3c0-0x3df (rw) Module Alias: pci:v1B36d0100sv1AF4sd1100bc03sc00i00 Driver Info #0: Driver Status: qxl is active Driver Activation Cmd: modprobe qxl Config Status: cfg=new, avail=yes, need=no, active=unknown Primary display adapter: #16 With driver installed should always fails with error similar a what I reported FWIK. I mean this: http://lists.xen.org/archives/html/xen-devel/2015-04/txtGtntonxpzb.txt http://lists.xen.org/archives/html/xen-devel/2015-04/msg03064.html I'm not seeing that. Or you have domU with qxl driver installed, used and working? In this case we must find solution or workaround present in SLES12 and apply it also upstream if missed. The base system is SLES12, but Xen and the tools (including qemu) are fairly recent xen-unstable. So the only thing SLES12 specific would be domU kernel and qxl driver. Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
On 28/04/15 23:17, Jim Fehlig wrote: Jim Fehlig wrote: wei.l...@citrix.com wrote: Hi all We are now three months into 4.6 development window. This is an email to keep track of all the patch series I gathered. It is by no means complete and / or acurate. Feel free to reply this email with new projects or correct my misunderstanding. [...] * libxl: add qxl vga interface support for upstream qemu (fair) - Fabio Fantoni I've been working on SPICE support in the libvirt libxl driver and quickly came across the lack of support for qxl device. What is the status of this work? AFAICT, there was a v16 posted nearly a year ago with no comments http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html After playing with this more, I think the patch will need a LIBXL_HAVE_QXL or similar in libxl.h. I noticed this work was committed in the 4.3 dev cycle, but was reverted before the release by commit 5479961a, which describes problems with instructions that cannot be used for MMIO. Has any progress been made on that front? Is Fabio's patch the only piece missing to support qxl devices? I've tried Fabio's patch on top of fairly recent xen-unstable and don't see the issues mentioned in the commit message of 5479961a. Note that I only tried linux HVM guests though. 16byte decomposed instruction still don't get passed correctly to the device model. This has been discussed at the hackathon and plan is in place. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
Il 29/04/2015 12:23, Fabio Fantoni ha scritto:
Il 29/04/2015 02:21, Andrew Cooper ha scritto:
On 28/04/15 23:17, Jim Fehlig wrote:
Jim Fehlig wrote:
wei.l...@citrix.com wrote:
Hi all
We are now three months into 4.6 development window. This is an
email to keep
track of all the patch series I gathered. It is by no means
complete and / or
acurate. Feel free to reply this email with new projects or
correct my
misunderstanding.
[...]
* libxl: add qxl vga interface support for upstream qemu (fair)
- Fabio Fantoni
I've been working on SPICE support in the libvirt libxl driver and
quickly came across the lack of support for qxl device. What is the
status of this work? AFAICT, there was a v16 posted nearly a year ago
with no comments
http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html
After playing with this more, I think the patch will need a
LIBXL_HAVE_QXL or similar in libxl.h.
I noticed this work was committed in the 4.3 dev cycle, but was
reverted
before the release by commit 5479961a, which describes problems with
instructions that cannot be used for MMIO. Has any progress been
made
on that front? Is Fabio's patch the only piece missing to support qxl
devices?
I've tried Fabio's patch on top of fairly recent xen-unstable and don't
see the issues mentioned in the commit message of 5479961a. Note that I
only tried linux HVM guests though.
qxl vga is working good on windows domUs except problem after
save/restore
on linux domUs instead I wasn't able to get it working
today I tried with fedora 22 (beta3) lxde live dvd (have included
latest qxl drivers available): with both stdvga and qxl mouse is
working but not visible and I not understand why, I'll try also
lubuntu 15.04.
can you tell me what dom0 and domU have you use for test please?
16byte decomposed instruction still don't get passed correctly to the
device model.
This has been discussed at the hackathon and plan is in place.
~Andrew
Thanks, is there any eta of possible solution?
Thanks for any reply and sorry for my bad english.
I tried with lubuntu 15.04 with qxl on latest xen-unstable and qemu crashed:
#0 __memset_sse2 () at ../sysdeps/x86_64/multiarch/../memset.S:908
Latest istruction:
= 0x73713f7b __memset_sse2+2363:movntdq %xmm0,(%rdi)
In attachment full backtrace, registers, istructions ecc... if can be useful
The linux domUs problem with qxl seems related to what Andrew told.
Added also Jan Beulich, he did one or more patches for try to solves it
time ago if I remember good.
Full backtrace:
#0 __memset_sse2 () at ../sysdeps/x86_64/multiarch/../memset.S:908
No locals.
#1 0x7482cbc0 in memset (__len=3145728, __ch=0, __dest=0x7fffdbe17000)
at /usr/include/x86_64-linux-gnu/bits/string3.h:85
No locals.
#2 red_create_surface (worker=0x7fffe41f4010, surface_id=4, width=1024,
height=768, stride=4096, format=32, line_0=0x7fffdbb18000, data_is_valid=0,
send_client=1) at red_worker.c:9617
surface = 0x7fffe41f4550
i = optimized out
#3 0x748386b5 in red_process_surface (worker=0x7fffe41f4010,
surface=0x563c3dd0, group_id=1, loadvm=0) at red_worker.c:4279
height = optimized out
stride = optimized out
reloaded_surface = optimized out
surface_id = 4
red_surface = 0x7fffe41f4550
data = optimized out
__FUNCTION__ = red_process_surface
#4 0x7483bafc in red_process_commands
(worker=worker@entry=0x7fffe41f4010,
ring_is_empty=ring_is_empty@entry=0x7fffe4bcdc6c, max_pipe_size=50) at
red_worker.c:5095
surface = 0x563c3dd0
ext_cmd = {cmd = {data = 72057594038145664, type = 5, padding =
4294967295}, group_id = 1, flags = 0}
n = 0
#5 0x74841334 in red_worker_main (arg=optimized out) at
red_worker.c:12191
ring_is_empty = 0
i = optimized out
num_events = 0
timers_queue_timeout = optimized out
worker = 0x7fffe41f4010
__FUNCTION__ = red_worker_main
#6 0x73a22b50 in start_thread (arg=optimized out) at
pthread_create.c:304
__res = optimized out
pd = 0x7fffe4bce700
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737030973184,
-1109939810272634058, 140737280922144, 140737030973888, 140737354125376, 3,
1109990962358295350, 1109949136377912118}, mask_was_saved = 0}}, priv = {pad =
{0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = optimized out
freesize = optimized out
__PRETTY_FUNCTION__ = start_thread
#7 0x7376c95d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
No locals.
#8 0x in ?? ()
No symbol table info available.
Registers:
rax0x7fffdbe17000 140736882372608
rbx0x7fffe41f4550 140737020642640
rcx0x0 0
rdx0x0 0
rsi0x0 0
rdi0x7fffdbf52000 140736883662848
rbp
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
Il 29/04/2015 02:21, Andrew Cooper ha scritto: On 28/04/15 23:17, Jim Fehlig wrote: Jim Fehlig wrote: wei.l...@citrix.com wrote: Hi all We are now three months into 4.6 development window. This is an email to keep track of all the patch series I gathered. It is by no means complete and / or acurate. Feel free to reply this email with new projects or correct my misunderstanding. [...] * libxl: add qxl vga interface support for upstream qemu (fair) - Fabio Fantoni I've been working on SPICE support in the libvirt libxl driver and quickly came across the lack of support for qxl device. What is the status of this work? AFAICT, there was a v16 posted nearly a year ago with no comments http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html After playing with this more, I think the patch will need a LIBXL_HAVE_QXL or similar in libxl.h. I noticed this work was committed in the 4.3 dev cycle, but was reverted before the release by commit 5479961a, which describes problems with instructions that cannot be used for MMIO. Has any progress been made on that front? Is Fabio's patch the only piece missing to support qxl devices? I've tried Fabio's patch on top of fairly recent xen-unstable and don't see the issues mentioned in the commit message of 5479961a. Note that I only tried linux HVM guests though. qxl vga is working good on windows domUs except problem after save/restore on linux domUs instead I wasn't able to get it working today I tried with fedora 22 (beta3) lxde live dvd (have included latest qxl drivers available): with both stdvga and qxl mouse is working but not visible and I not understand why, I'll try also lubuntu 15.04. can you tell me what dom0 and domU have you use for test please? 16byte decomposed instruction still don't get passed correctly to the device model. This has been discussed at the hackathon and plan is in place. ~Andrew Thanks, is there any eta of possible solution? Thanks for any reply and sorry for my bad english. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
Fabio Fantoni wrote: Il 29/04/2015 02:21, Andrew Cooper ha scritto: On 28/04/15 23:17, Jim Fehlig wrote: Jim Fehlig wrote: wei.l...@citrix.com wrote: Hi all We are now three months into 4.6 development window. This is an email to keep track of all the patch series I gathered. It is by no means complete and / or acurate. Feel free to reply this email with new projects or correct my misunderstanding. [...] * libxl: add qxl vga interface support for upstream qemu (fair) - Fabio Fantoni I've been working on SPICE support in the libvirt libxl driver and quickly came across the lack of support for qxl device. What is the status of this work? AFAICT, there was a v16 posted nearly a year ago with no comments http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html After playing with this more, I think the patch will need a LIBXL_HAVE_QXL or similar in libxl.h. I noticed this work was committed in the 4.3 dev cycle, but was reverted before the release by commit 5479961a, which describes problems with instructions that cannot be used for MMIO. Has any progress been made on that front? Is Fabio's patch the only piece missing to support qxl devices? I've tried Fabio's patch on top of fairly recent xen-unstable and don't see the issues mentioned in the commit message of 5479961a. Note that I only tried linux HVM guests though. qxl vga is working good on windows domUs except problem after save/restore on linux domUs instead I wasn't able to get it working today I tried with fedora 22 (beta3) lxde live dvd (have included latest qxl drivers available): with both stdvga and qxl mouse is working but not visible and I not understand why, I'll try also lubuntu 15.04. can you tell me what dom0 and domU have you use for test please? dom0 and domU are both SLES12. Xen is fairly recent xen-unstable plus a few libxl patches. Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
Jim Fehlig wrote: wei.l...@citrix.com wrote: Hi all We are now three months into 4.6 development window. This is an email to keep track of all the patch series I gathered. It is by no means complete and / or acurate. Feel free to reply this email with new projects or correct my misunderstanding. [...] * libxl: add qxl vga interface support for upstream qemu (fair) - Fabio Fantoni I've been working on SPICE support in the libvirt libxl driver and quickly came across the lack of support for qxl device. What is the status of this work? AFAICT, there was a v16 posted nearly a year ago with no comments http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html After playing with this more, I think the patch will need a LIBXL_HAVE_QXL or similar in libxl.h. I noticed this work was committed in the 4.3 dev cycle, but was reverted before the release by commit 5479961a, which describes problems with instructions that cannot be used for MMIO. Has any progress been made on that front? Is Fabio's patch the only piece missing to support qxl devices? I've tried Fabio's patch on top of fairly recent xen-unstable and don't see the issues mentioned in the commit message of 5479961a. Note that I only tried linux HVM guests though. Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
wei.l...@citrix.com wrote: Hi all We are now three months into 4.6 development window. This is an email to keep track of all the patch series I gathered. It is by no means complete and / or acurate. Feel free to reply this email with new projects or correct my misunderstanding. [...] * libxl: add qxl vga interface support for upstream qemu (fair) - Fabio Fantoni I've been working on SPICE support in the libvirt libxl driver and quickly came across the lack of support for qxl device. What is the status of this work? AFAICT, there was a v16 posted nearly a year ago with no comments http://lists.xen.org/archives/html/xen-devel/2014-05/msg03214.html I noticed this work was committed in the 4.3 dev cycle, but was reverted before the release by commit 5479961a, which describes problems with instructions that cannot be used for MMIO. Has any progress been made on that front? Is Fabio's patch the only piece missing to support qxl devices? Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
On 15 Apr 2015, at 10:18, Jan Beulich jbeul...@suse.com wrote: Should we also ask people to trim the CC list to just those interested in the quoted stuff? Or do people think that erring on the side of not trimming too many people? People might also to consider changing the subject, e.g. Status of $FOO (Was: Xen 4.6 Development Update (three months reminder)). Both good ideas imo. +1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
On Tue, 2015-04-14 at 11:37 +0100, Wei Liu wrote: On Tue, Apr 14, 2015 at 01:34:45PM +0300, Razvan Cojocaru wrote: On 04/14/2015 01:27 PM, wei.l...@citrix.com wrote: * VM event patches (none) Add support for XSETBV vm_events, Support hybernating guests Support for VMCALL-based vm_events - Razvan Cojocaru These depend on Tamas' Clean-up of mem-event subsystem series (which hasn't been applied in its entirety). If you prefer, I can apply Tamas' patches manually on a fresh Xen mainline copy and start sending out our patches built on top of that. What do you think? This email is just a general reminder of our development cycle. There is no need to rush IMHO. You still have several months. More generally though it is find IMHO to send out a series which depends on another so long as the 00/NN email clearly explains what it needs to be applied on top of (i.e. a reference to the specific version of the other series). You should omit that other tree when posting, by passing git send-email the correct range to just send your own stuff. And under such circumstances it might also be a good idea to also include a git url, to make it easier for people to pickup the right set of things. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
On Tue, 2015-04-14 at 14:52 +0100, Wei Liu wrote: On Tue, Apr 14, 2015 at 02:48:06PM +0100, Jan Beulich wrote: On 14.04.15 at 15:35, tamas.leng...@zentific.com wrote: On Tue, Apr 14, 2015 at 12:27 PM, wei.l...@citrix.com wrote: Tamas (and others not doing so) - please trim your quotes in replies. Wei - could you add a sentence saying so near the top of future mails you send in this regard? No problem. Should we also ask people to trim the CC list to just those interested in the quoted stuff? Or do people think that erring on the side of not trimming too many people? People might also to consider changing the subject, e.g. Status of $FOO (Was: Xen 4.6 Development Update (three months reminder)). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
On 15.04.15 at 11:11, ian.campb...@citrix.com wrote: On Tue, 2015-04-14 at 14:52 +0100, Wei Liu wrote: On Tue, Apr 14, 2015 at 02:48:06PM +0100, Jan Beulich wrote: On 14.04.15 at 15:35, tamas.leng...@zentific.com wrote: On Tue, Apr 14, 2015 at 12:27 PM, wei.l...@citrix.com wrote: Tamas (and others not doing so) - please trim your quotes in replies. Wei - could you add a sentence saying so near the top of future mails you send in this regard? No problem. Should we also ask people to trim the CC list to just those interested in the quoted stuff? Or do people think that erring on the side of not trimming too many people? People might also to consider changing the subject, e.g. Status of $FOO (Was: Xen 4.6 Development Update (three months reminder)). Both good ideas imo. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
From: xen-devel-boun...@lists.xen.org xen-devel-boun...@lists.xen.org on behalf of wei.l...@citrix.com wei.l...@citrix.com Sent: Tuesday, April 14, 2015 3:57 PM To: xen-de...@lists.xenproject.org; edmund.h.wh...@intel.com; xumengpa...@gmail.com; dgol...@seas.upenn.edu; jtwea...@hawaii.edu; oleksandr.dmytrys...@globallogic.com; cheg...@amazon.de; daniel.ki...@oracle.com; george.dun...@eu.citrix.com; rcojoc...@bitdefender.com; chao.p.p...@linux.intel.com; feng...@intel.com; dario.faggi...@citrix.com; ross.lagerw...@citrix.com; malcolm.cross...@citrix.com; kai.hu...@linux.intel.com; tiejun.c...@intel.com; boris.ostrov...@oracle.com; elena.ufimts...@oracle.com; tamas.leng...@zentific.com; Kumar, Vijaya; parth.di...@linaro.org; ian.campb...@citrix.com; andrii.tseglyts...@globallogic.com; suravee.suthikulpa...@amd.com; julien.gr...@linaro.org; manishjaggi@gmail.com; vijay.kil...@gmail.com; vkuzn...@redhat.com; fabio.fant...@m2r.biz; ian.jack...@eu.citrix.com; dsl...@verizon.com; cy...@suse.com; jgr...@suse.com; o...@aepfle.de; we...@cn.fujitsu.com; guijianf...@cn.fujitsu.com; andrew.coop...@citrix.com; david.vra...@citrix.com; bob@oracle.com; yan...@cn.fujitsu.com; roger@citrix.com; konrad.w...@oracle.com; eshel...@pobox.com; wei.l...@citrix.com; eddie.d...@intel.com; julien.gr...@citrix.com; anthony.per...@citrix.com; tal...@gmail.com; artem.myga...@globallogic.com; robert...@intel.com; wei.l...@citrix.com; edgar.igles...@gmail.com; frediano.zig...@huawei.com; ard.biesheu...@linaro.org; quan...@intel.com; oleksandr.tyshche...@globallogic.com Subject: [Xen-devel] Xen 4.6 Development Update (three months reminder) Hi all We are now three months into 4.6 development window. This is an email to keep track of all the patch series I gathered. It is by no means complete and / or acurate. Feel free to reply this email with new projects or correct my misunderstanding. = Timeline = We are planning on a 9-month release cycle, but we could also release a bit earlier if everything goes well (no blocker, no critical bug). * Development start: 6 Jan 2015 === We are here === * Feature Freeze: 10 Jul 2015 * RCs: TBD * Release Date: 9 Oct 2015 (could release earlier) The RCs and release will of course depend on stability and bugs, and will therefore be fairly unpredictable. Bug-fixes, if Acked-by by maintainer, can go anytime before the First RC. Later on we will need to figure out the risk of regression/reward to eliminate the possiblity of a bug introducing another bug. = Prognosis = The states are: none - fair - ok - good - done none - nothing yet fair - still working on it, patches are prototypes or RFC ok - patches posted, acting on review good - some last minute pieces done - all done, might have bugs = Bug Fixes = Bug fixes can be checked in without a freeze exception throughout the freeze, unless the maintainer thinks they are particularly high risk. In later RC's, we may even begin rejecting bug fixes if the broken functionality is small and the risk to other functionality is high. Document changes can go in anytime if the maintainer is OK with it. These are guidelines and principles to give you an idea where we're coming from; if you think there's a good reason why making an exception for you will help us make Xen better than not doing so, feel free to make your case. == Hypervisor == * Alternate p2m: support multiple copies of host p2m (ok) - Ed White * Improve RTDS scheduler (none) - Dagaen Golomb, Meng Xu * Credit2: introduce per-vcpu hard and soft affinity (good) - Justin T. Weaver * sndif: add API for para-virtual sound (fair) v7 posted - Oleksandr Dmytryshyn * gnttab: improve scalability (good) v5 posted - Christoph Egger * Display IO topology when PXM data is available (good) v3 posted - Boris Ostrovsky * Xen multiboot2-EFI support (fair) See http://lists.xen.org/archives/html/xen-devel/2013-05/msg02281.html RFC posted - Daniel Kiper * Credit2 production ready (none) cpu pinning, numa affinity and cpu reservation - George Dunlap * VM event patches (none) Add support for XSETBV vm_events, Support hybernating guests Support for VMCALL-based vm_events - Razvan Cojocaru === Hypervisor X86 === * Intel Cache Allocation Technology (good) - Chao Peng * VT-d Posted-interrupt (PI) (none) - Wu, Feng * HT enabled with credit has 7.9 per perf drop. (none) kernbench demonstrated it http://www.gossamer-threads.com/lists/xen/devel/339409 This has existed since credit1 introduction. - Dario Faggioli * Support controlling the max C-state sub-state (fair) v3 posted Hadn't see the patch reposted. - Ross Lagerwall * IOMMU ABI for guests to map their DMA regions (fair) - Malcolm Crossley * Intel PML (Page Modification Logging) for Xen (none) design doc posted - Kai Huang * RMRR fix (fair) RFC posted - Tiejun Chen * VPMU
[Xen-devel] Xen 4.6 Development Update (three months reminder)
Hi all We are now three months into 4.6 development window. This is an email to keep track of all the patch series I gathered. It is by no means complete and / or acurate. Feel free to reply this email with new projects or correct my misunderstanding. = Timeline = We are planning on a 9-month release cycle, but we could also release a bit earlier if everything goes well (no blocker, no critical bug). * Development start: 6 Jan 2015 === We are here === * Feature Freeze: 10 Jul 2015 * RCs: TBD * Release Date: 9 Oct 2015 (could release earlier) The RCs and release will of course depend on stability and bugs, and will therefore be fairly unpredictable. Bug-fixes, if Acked-by by maintainer, can go anytime before the First RC. Later on we will need to figure out the risk of regression/reward to eliminate the possiblity of a bug introducing another bug. = Prognosis = The states are: none - fair - ok - good - done none - nothing yet fair - still working on it, patches are prototypes or RFC ok - patches posted, acting on review good - some last minute pieces done - all done, might have bugs = Bug Fixes = Bug fixes can be checked in without a freeze exception throughout the freeze, unless the maintainer thinks they are particularly high risk. In later RC's, we may even begin rejecting bug fixes if the broken functionality is small and the risk to other functionality is high. Document changes can go in anytime if the maintainer is OK with it. These are guidelines and principles to give you an idea where we're coming from; if you think there's a good reason why making an exception for you will help us make Xen better than not doing so, feel free to make your case. == Hypervisor == * Alternate p2m: support multiple copies of host p2m (ok) - Ed White * Improve RTDS scheduler (none) - Dagaen Golomb, Meng Xu * Credit2: introduce per-vcpu hard and soft affinity (good) - Justin T. Weaver * sndif: add API for para-virtual sound (fair) v7 posted - Oleksandr Dmytryshyn * gnttab: improve scalability (good) v5 posted - Christoph Egger * Display IO topology when PXM data is available (good) v3 posted - Boris Ostrovsky * Xen multiboot2-EFI support (fair) See http://lists.xen.org/archives/html/xen-devel/2013-05/msg02281.html RFC posted - Daniel Kiper * Credit2 production ready (none) cpu pinning, numa affinity and cpu reservation - George Dunlap * VM event patches (none) Add support for XSETBV vm_events, Support hybernating guests Support for VMCALL-based vm_events - Razvan Cojocaru === Hypervisor X86 === * Intel Cache Allocation Technology (good) - Chao Peng * VT-d Posted-interrupt (PI) (none) - Wu, Feng * HT enabled with credit has 7.9 per perf drop. (none) kernbench demonstrated it http://www.gossamer-threads.com/lists/xen/devel/339409 This has existed since credit1 introduction. - Dario Faggioli * Support controlling the max C-state sub-state (fair) v3 posted Hadn't see the patch reposted. - Ross Lagerwall * IOMMU ABI for guests to map their DMA regions (fair) - Malcolm Crossley * Intel PML (Page Modification Logging) for Xen (none) design doc posted - Kai Huang * RMRR fix (fair) RFC posted - Tiejun Chen * VPMU - 'perf' support in Xen (good) v14 posted Need reviews/final ack. - Boris Ostrovsky * PVH - AMD hardware support. (fair) RFC posted - Elena Ufimtseva * PVH dom0 (fair) RFC posted - Elena Ufimtseva === Hypervisor ARM === * Mem_access for ARM (good) v13 posted - Tamas K Lengyel * ITS support (fair ) - Vijaya Kumar K * Add ACPI support for arm64 on Xen (fair) RFC posted - Parth Dixit * ARM: reenable support 32-bit userspace running in 64-bit guest (good) v2 posted - Ian Campbell * ARM remote processor iommu module (GPUs + IPUs) (fair) v3 posted - Andrii Tseglytskyi * ARM VM save/restore/live migration (none) Need to rebased against migrationv2 - no code posted. - None * ARM GICv2m support (none) - Suravee Suthikulanit * ARM - passthrough of non-PCI (ok) - Julien Grall * ARM PCI passthrough (none) - Manish Jaggi - Vijay Kilari == Xen toolstack == * toolstack-based approach to pvhvm guest kexec (fair) also contains hypervisor side change - Vitaly Kuznetsov * libxl: add qxl vga interface support for upstream qemu (fair) - Fabio Fantoni * Toolstack-based approach to pvhvm guest kexec (ok) v4 posted - Vitaly Kuznetsov * libxl: cancelling asynchronous operations (fair) RFC posted - Ian Jackson * VMware tools support (fair) - Don Slutz * PV USB support in libxl (fair) - Chunyan Liu * HVM USB support in libxl (fair) - George Dunlap * Blktap2 support (fair) - George Dunlap * pvscsi in libxl (fair) - Juergen Gross and Olaf * COarse-grain LOck-stepping Virtual Machines in Xen (fair) RFC v5 posted - Wen Congyang - Gui Jianfeng - Yang
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
On 04/14/2015 11:27 AM, wei.l...@citrix.com wrote: == Hypervisor == * Alternate p2m: support multiple copies of host p2m (ok) - Ed White * Improve RTDS scheduler (none) - Dagaen Golomb, Meng Xu This is a little vague... exactly what kinds of improvements are envisioned here? * Credit2: introduce per-vcpu hard and soft affinity (good) - Justin T. Weaver Still good (Probably in part awaiting my further review -- should get to that this week) * Credit2 production ready (none) cpu pinning, numa affinity and cpu reservation - George Dunlap The first two are identical to Justin Weaver's patch; you might want to note that. No work on CPU reservation yet. * PV USB support in libxl (fair) - Chunyan Liu * HVM USB support in libxl (fair) - George Dunlap Haven't heard anything on the first one in a while; the second one is basically blocked on the first. * Blktap2 support (fair) - George Dunlap Working on integrating this with raisin; still fair by the definitions above. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
On Tue, Apr 14, 2015 at 12:27 PM, wei.l...@citrix.com wrote: Hi all We are now three months into 4.6 development window. This is an email to keep track of all the patch series I gathered. It is by no means complete and / or acurate. Feel free to reply this email with new projects or correct my misunderstanding. = Timeline = We are planning on a 9-month release cycle, but we could also release a bit earlier if everything goes well (no blocker, no critical bug). * Development start: 6 Jan 2015 === We are here === * Feature Freeze: 10 Jul 2015 * RCs: TBD * Release Date: 9 Oct 2015 (could release earlier) The RCs and release will of course depend on stability and bugs, and will therefore be fairly unpredictable. Bug-fixes, if Acked-by by maintainer, can go anytime before the First RC. Later on we will need to figure out the risk of regression/reward to eliminate the possiblity of a bug introducing another bug. = Prognosis = The states are: none - fair - ok - good - done none - nothing yet fair - still working on it, patches are prototypes or RFC ok - patches posted, acting on review good - some last minute pieces done - all done, might have bugs = Bug Fixes = Bug fixes can be checked in without a freeze exception throughout the freeze, unless the maintainer thinks they are particularly high risk. In later RC's, we may even begin rejecting bug fixes if the broken functionality is small and the risk to other functionality is high. Document changes can go in anytime if the maintainer is OK with it. These are guidelines and principles to give you an idea where we're coming from; if you think there's a good reason why making an exception for you will help us make Xen better than not doing so, feel free to make your case. == Hypervisor == * Alternate p2m: support multiple copies of host p2m (ok) - Ed White * Improve RTDS scheduler (none) - Dagaen Golomb, Meng Xu * Credit2: introduce per-vcpu hard and soft affinity (good) - Justin T. Weaver * sndif: add API for para-virtual sound (fair) v7 posted - Oleksandr Dmytryshyn * gnttab: improve scalability (good) v5 posted - Christoph Egger * Display IO topology when PXM data is available (good) v3 posted - Boris Ostrovsky * Xen multiboot2-EFI support (fair) See http://lists.xen.org/archives/html/xen-devel/2013-05/msg02281.html RFC posted - Daniel Kiper * Credit2 production ready (none) cpu pinning, numa affinity and cpu reservation - George Dunlap * VM event patches (none) Add support for XSETBV vm_events, Support hybernating guests Support for VMCALL-based vm_events - Razvan Cojocaru === Hypervisor X86 === * Intel Cache Allocation Technology (good) - Chao Peng * VT-d Posted-interrupt (PI) (none) - Wu, Feng * HT enabled with credit has 7.9 per perf drop. (none) kernbench demonstrated it http://www.gossamer-threads.com/lists/xen/devel/339409 This has existed since credit1 introduction. - Dario Faggioli * Support controlling the max C-state sub-state (fair) v3 posted Hadn't see the patch reposted. - Ross Lagerwall * IOMMU ABI for guests to map their DMA regions (fair) - Malcolm Crossley * Intel PML (Page Modification Logging) for Xen (none) design doc posted - Kai Huang * RMRR fix (fair) RFC posted - Tiejun Chen * VPMU - 'perf' support in Xen (good) v14 posted Need reviews/final ack. - Boris Ostrovsky * PVH - AMD hardware support. (fair) RFC posted - Elena Ufimtseva * PVH dom0 (fair) RFC posted - Elena Ufimtseva === Hypervisor ARM === * Mem_access for ARM (good) v13 posted - Tamas K Lengyel v14 has been posted as well, v15 will be sent this week. * ITS support (fair ) - Vijaya Kumar K * Add ACPI support for arm64 on Xen (fair) RFC posted - Parth Dixit * ARM: reenable support 32-bit userspace running in 64-bit guest (good) v2 posted - Ian Campbell * ARM remote processor iommu module (GPUs + IPUs) (fair) v3 posted - Andrii Tseglytskyi * ARM VM save/restore/live migration (none) Need to rebased against migrationv2 - no code posted. - None * ARM GICv2m support (none) - Suravee Suthikulanit * ARM - passthrough of non-PCI (ok) - Julien Grall * ARM PCI passthrough (none) - Manish Jaggi - Vijay Kilari == Xen toolstack == * toolstack-based approach to pvhvm guest kexec (fair) also contains hypervisor side change - Vitaly Kuznetsov * libxl: add qxl vga interface support for upstream qemu (fair) - Fabio Fantoni * Toolstack-based approach to pvhvm guest kexec (ok) v4 posted - Vitaly Kuznetsov * libxl: cancelling asynchronous operations (fair) RFC posted - Ian Jackson * VMware tools support (fair) - Don Slutz * PV USB support in libxl (fair) - Chunyan Liu * HVM USB
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
On 14/04/15 11:27, wei.l...@citrix.com wrote: === Hypervisor X86 === * VT-d Posted-interrupt (PI) (none) - Wu, Feng V1 posted * Intel PML (Page Modification Logging) for Xen (none) design doc posted - Kai Huang V1 posted (good) * PVH - AMD hardware support. (fair) RFC posted - Elena Ufimtseva I am not aware of any patches along these lines? == Xen toolstack == * New Migration (v2). (good) v9 (libxc) git://xenbits.xen.org/people/andrewcoop/xen.git Seems that it might need to slip or we run v1 alongside v2. - Andrew Cooper David Vrabel Hopefully no need to slip, but there are very good reasons to run v1 alongside v2. * PVH - Migration of guests from a PVH dom0 (none) Depends on migration2 code - Roger Pau Monné v1 posted. == Deferred == * ucode=scan also scan compressed initramfs (none) - Konrad Rzeszutek Wilk * adjust log buffer based on memmap size (none) - Konrad Rzeszutek Wilk * Further tmem cleanups/fixes (fair) - Bob Liu * 1TB slow destruction (ok) - Bob Liu * cpuid leveling (none) http://xenbits.xen.org/people/andrewcoop/feature-levelling/feature-levelling-D.pdf - Andrew Cooper Now starting active work on this, but I can't say yet whether it is even plausible to be done in the 4.6 timeframe. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
* Regression in PCI passthrough of INTx legacy devices can trigger list corruption (good) Sander reported it. Two different types of patches available. - Konrad Rzeszutek Wilk Done. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
On Tue, 2015-04-14 at 13:34 +0100, Julien Grall wrote: Hi Manish, On 14/04/15 13:25, Jaggi, Manish wrote: * ARM PCI passthrough (none) - Manish Jaggi - Vijay Kilari [manish] I have started pushing the patches Finding the [manish] in the mail was like finding a needle in a haystack. And I knew that you were using this tag... Please only quote the relevant part of the mail. I would also advice you to configure your email client correctly in order to avoid the tag. +2 (thousand). ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
On 04/14/2015 06:27 AM, wei.l...@citrix.com wrote: * Display IO topology when PXM data is available (good) v3 posted - Boris Ostrovsky I should have v7 in the next day or so. * VPMU - 'perf' support in Xen (good) v14 posted Need reviews/final ack. - Boris Ostrovsky New version posted a week or so ago, there were very few changes. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
On 4/14/2015 at 09:33 PM, in message 552d1718.8060...@eu.citrix.com, George Dunlap george.dun...@eu.citrix.com wrote: On 04/14/2015 11:27 AM, wei.l...@citrix.com wrote: == Hypervisor == * Alternate p2m: support multiple copies of host p2m (ok) - Ed White * Improve RTDS scheduler (none) - Dagaen Golomb, Meng Xu This is a little vague... exactly what kinds of improvements are envisioned here? * Credit2: introduce per-vcpu hard and soft affinity (good) - Justin T. Weaver Still good (Probably in part awaiting my further review -- should get to that this week) * Credit2 production ready (none) cpu pinning, numa affinity and cpu reservation - George Dunlap The first two are identical to Justin Weaver's patch; you might want to note that. No work on CPU reservation yet. * PV USB support in libxl (fair) - Chunyan Liu * HVM USB support in libxl (fair) - George Dunlap Haven't heard anything on the first one in a while; the second one is basically blocked on the first. New version should be posted this week, addressing all comments of last version. * Blktap2 support (fair) - George Dunlap Working on integrating this with raisin; still fair by the definitions above. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
2015-04-14 9:33 GMT-04:00 George Dunlap george.dun...@eu.citrix.com: On 04/14/2015 11:27 AM, wei.l...@citrix.com wrote: == Hypervisor == * Alternate p2m: support multiple copies of host p2m (ok) - Ed White * Improve RTDS scheduler (none) - Dagaen Golomb, Meng Xu This is a little vague... exactly what kinds of improvements are envisioned here? We are changing the RTDS scheduler from quantum driven to event driven. In other words, we will only invoke the RTDS scheduler at specific scheduling event (such as VCPU budget replenishment, VCPU wake up, VCPU deadline arrives). This will reduce the frequency of invoking the RTDS scheduler and thus reduce the scheduling overhead in hypervisor. Another improvement is supporting getting/setting each VCPU's parameters in xl tool. Chong Li (chong...@wustl.edu), cc.ed, is working on this right now. He will finish the first version of the patch soon and we will go though some internal code review before sending out the patch to the mailing list. As to the progress, Dagaen finished the first version of the patch and we are going through internal code review and refining the code. We will send out the patch to the mailing list once we are satisfied with the code. (The status about this item should be marked as none now.) Thanks, Meng * Credit2: introduce per-vcpu hard and soft affinity (good) - Justin T. Weaver Still good (Probably in part awaiting my further review -- should get to that this week) * Credit2 production ready (none) cpu pinning, numa affinity and cpu reservation - George Dunlap The first two are identical to Justin Weaver's patch; you might want to note that. No work on CPU reservation yet. * PV USB support in libxl (fair) - Chunyan Liu * HVM USB support in libxl (fair) - George Dunlap Haven't heard anything on the first one in a while; the second one is basically blocked on the first. * Blktap2 support (fair) - George Dunlap Working on integrating this with raisin; still fair by the definitions above. -George -- --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
On Tue, Apr 14, 2015 at 02:33:23PM +0100, Wei Liu wrote: On Tue, Apr 14, 2015 at 02:28:29PM +0100, Andrew Cooper wrote: On 14/04/15 11:27, wei.l...@citrix.com wrote: === Hypervisor X86 === * VT-d Posted-interrupt (PI) (none) - Wu, Feng V1 posted * Intel PML (Page Modification Logging) for Xen (none) design doc posted - Kai Huang V1 posted (good) * PVH - AMD hardware support. (fair) RFC posted - Elena Ufimtseva I am not aware of any patches along these lines? I've seen some patches from Elena that look related to AMD PVH. Maybe I'm mistaken. I will let her confirm. Wei I will be reposting Mukesh PVH DomU patches shortly, but so far there were no AMD patches from me. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
Hi Manish, On 14/04/15 13:25, Jaggi, Manish wrote: * ARM PCI passthrough (none) - Manish Jaggi - Vijay Kilari [manish] I have started pushing the patches Finding the [manish] in the mail was like finding a needle in a haystack. And I knew that you were using this tag... Please only quote the relevant part of the mail. I would also advice you to configure your email client correctly in order to avoid the tag. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
