Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET from Dom0
Hello, El 18/12/14 a les 19.51, Andrew Cooper ha escrit: On 18/12/14 18:27, Roger Pau Monne wrote: Prevent Dom0 from accessing HPET MMIO region by adding it to the list of denied memory regions. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Jan Beulich jbeul...@suse.com Cc: Andrew Cooper andrew.coop...@citrix.com Apologies that this reply is split between patch 0 and 2 - I replied to your cover letter before reading this patch. Denying access is only valid if acpi_table_hpet.flags ACPI_HPET_PAGE_PROTECT4 is true. Thanks, if ACPI_HPET_PAGE_PROTECT4 is set then we can prevent access to the full page and if ACPI_HPET_PAGE_PROTECT64 is set we can prevent access to this page and the adjacent 60KB (15 pages). Will send an updated version. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/2] VT-d: extend XSA-59 workaround
The endless story continues. 1: make XSA-59 workaround fully cover XeonE5/E7 v2 2: extend XSA-59 workaround to XeonE5 v3 (Haswell) Signed-off-by: Jan Beulich jbeul...@suse.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] VT-d: make XSA-59 workaround fully cover XeonE5/E7 v2
So far only the VT-d UR masking was being done for them. Signed-off-by: Jan Beulich jbeul...@suse.com --- a/xen/drivers/passthrough/vtd/quirks.c +++ b/xen/drivers/passthrough/vtd/quirks.c @@ -440,6 +440,9 @@ void pci_vtd_quirk(const struct pci_dev seg, bus, dev, func); break; +/* Xeon E5/E7 v2 */ +case 0x0e00: /* host bridge */ +case 0x0e01: case 0x0e04 ... 0x0e0b: /* root ports */ /* Tylersburg (EP)/Boxboro (MP) chipsets (NHM-EP/EX, WSM-EP/EX) */ case 0x3400 ... 0x3407: /* host bridges */ case 0x3408 ... 0x3411: case 0x3420 ... 0x3421: /* root ports */ VT-d: make XSA-59 workaround fully cover XeonE5/E7 v2 So far only the VT-d UR masking was being done for them. Signed-off-by: Jan Beulich jbeul...@suse.com --- a/xen/drivers/passthrough/vtd/quirks.c +++ b/xen/drivers/passthrough/vtd/quirks.c @@ -440,6 +440,9 @@ void pci_vtd_quirk(const struct pci_dev seg, bus, dev, func); break; +/* Xeon E5/E7 v2 */ +case 0x0e00: /* host bridge */ +case 0x0e01: case 0x0e04 ... 0x0e0b: /* root ports */ /* Tylersburg (EP)/Boxboro (MP) chipsets (NHM-EP/EX, WSM-EP/EX) */ case 0x3400 ... 0x3407: /* host bridges */ case 0x3408 ... 0x3411: case 0x3420 ... 0x3421: /* root ports */ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] VT-d: extend XSA-59 workaround to XeonE5 v3 (Haswell)
Note that the datasheet lacks PCI IDs for Dev 1 Fn 0-1, so their IDs are being added based on what https://pci-ids.ucw.cz/read/PC/8086 says. Signed-off-by: Jan Beulich jbeul...@suse.com --- a/xen/drivers/passthrough/vtd/quirks.c +++ b/xen/drivers/passthrough/vtd/quirks.c @@ -431,6 +431,7 @@ void pci_vtd_quirk(const struct pci_dev * - Potential security issue if malicious guest trigger VT-d faults. */ case 0x0e28: /* Xeon-E5v2 (IvyBridge) */ +case 0x2f28: /* Xeon-E5v3 (Haswell) */ case 0x342e: /* Tylersburg chipset (Nehalem / Westmere systems) */ case 0x3728: /* Xeon C5500/C3500 (JasperForest) */ case 0x3c28: /* Sandybridge */ @@ -443,6 +444,9 @@ void pci_vtd_quirk(const struct pci_dev /* Xeon E5/E7 v2 */ case 0x0e00: /* host bridge */ case 0x0e01: case 0x0e04 ... 0x0e0b: /* root ports */ +/* Xeon E5 v3 */ +case 0x2f00: /* host bridge */ +case 0x2f01 ... 0x2f0b: /* root ports */ /* Tylersburg (EP)/Boxboro (MP) chipsets (NHM-EP/EX, WSM-EP/EX) */ case 0x3400 ... 0x3407: /* host bridges */ case 0x3408 ... 0x3411: case 0x3420 ... 0x3421: /* root ports */ VT-d: extend XSA-59 workaround to XeonE5 v3 (Haswell) Note that the datasheet lacks PCI IDs for Dev 1 Fn 0-1, so their IDs are being added based on what https://pci-ids.ucw.cz/read/PC/8086 says. Signed-off-by: Jan Beulich jbeul...@suse.com --- a/xen/drivers/passthrough/vtd/quirks.c +++ b/xen/drivers/passthrough/vtd/quirks.c @@ -431,6 +431,7 @@ void pci_vtd_quirk(const struct pci_dev * - Potential security issue if malicious guest trigger VT-d faults. */ case 0x0e28: /* Xeon-E5v2 (IvyBridge) */ +case 0x2f28: /* Xeon-E5v3 (Haswell) */ case 0x342e: /* Tylersburg chipset (Nehalem / Westmere systems) */ case 0x3728: /* Xeon C5500/C3500 (JasperForest) */ case 0x3c28: /* Sandybridge */ @@ -443,6 +444,9 @@ void pci_vtd_quirk(const struct pci_dev /* Xeon E5/E7 v2 */ case 0x0e00: /* host bridge */ case 0x0e01: case 0x0e04 ... 0x0e0b: /* root ports */ +/* Xeon E5 v3 */ +case 0x2f00: /* host bridge */ +case 0x2f01 ... 0x2f0b: /* root ports */ /* Tylersburg (EP)/Boxboro (MP) chipsets (NHM-EP/EX, WSM-EP/EX) */ case 0x3400 ... 0x3407: /* host bridges */ case 0x3408 ... 0x3411: case 0x3420 ... 0x3421: /* root ports */ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET from Dom0
On 18.12.14 at 19:27, roger@citrix.com wrote: --- a/xen/arch/x86/domain_build.c +++ b/xen/arch/x86/domain_build.c @@ -36,6 +36,9 @@ #include asm/bzimage.h /* for bzimage_parse */ #include asm/io_apic.h #include asm/hap.h +#ifdef CONFIG_HPET_TIMER +#include asm/hpet.h /* for hpet_address */ +#endif When you update the patch according to Andrew's comments, please also drop these stray #ifdef-s - if anything we should delete eventual other references to CONFIG_HPET_TIMER. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET from Dom0
On 18.12.14 at 19:51, andrew.coop...@citrix.com wrote: On 18/12/14 18:27, Roger Pau Monne wrote: Prevent Dom0 from accessing HPET MMIO region by adding it to the list of denied memory regions. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Jan Beulich jbeul...@suse.com Cc: Andrew Cooper andrew.coop...@citrix.com Apologies that this reply is split between patch 0 and 2 - I replied to your cover letter before reading this patch. Denying access is only valid if acpi_table_hpet.flags ACPI_HPET_PAGE_PROTECT4 is true. Somehow the existence of this indication slipped my attention so far; I had always wanted to hide the HPET page from Dom0 if possible. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 for-4.6 1/2] xen/pvh: check permissions when adding MMIO regions
On 18.12.14 at 20:05, andrew.coop...@citrix.com wrote:
On 18/12/14 18:27, Roger Pau Monne wrote:
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -312,16 +312,47 @@ static __init void pvh_add_mem_mapping(struct domain
*d, unsigned long gfn,
unsigned long mfn, unsigned long
nr_mfns)
{
unsigned long i;
+xenmem_access_t def_access;
+bool_t r_only = false;
int rc;
for ( i = 0; i nr_mfns; i++ )
{
+if ( !iomem_access_permitted(d, mfn + i, mfn + i) )
+goto next;
+
+if ( rangeset_contains_singleton(mmio_ro_ranges, mfn + i)
!r_only )
+{
+rc = p2m_get_mem_access(d, ~0ul, def_access);
+BUG_ON(rc);
+/* Set default access to read-only */
+rc = p2m_set_mem_access(d, ~0ul, 0, 0, 0, XENMEM_access_r);
+BUG_ON(rc);
+r_only = true;
+}
+else if ( r_only )
+{
+/* Set the default back */
+rc = p2m_set_mem_access(d, ~0ul, 0, 0, 0, def_access);
+BUG_ON(rc);
+r_only = false;
+}
Am I missing something obvious, or would all this r_only juggling be far
more easy if set_mmio_p2m_entry() had a ro/rw boolean parameter?
As these entries are done one at a time, it would seem to be far less
error prone to explicitly choose a read-only or read-write mmio mapping,
rather than playing with the entire default.
+1
+
if ( (rc = set_mmio_p2m_entry(d, gfn + i, _mfn(mfn + i))) )
panic(pvh_add_mem_mapping: gfn:%lx mfn:%lx i:%ld rc:%d\n,
gfn, mfn, i, rc);
+
+ next:
if ( !(i 0xf) )
process_pending_softirqs();
You could remove the next label by moving this clause to the top and
adding an i != 0 check.
Or really just make the respective goto a continue - we know we
don't hide overly large regions from Dom0.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET from Dom0
On 18.12.14 at 19:51, andrew.coop...@citrix.com wrote: On 18/12/14 18:27, Roger Pau Monne wrote: Prevent Dom0 from accessing HPET MMIO region by adding it to the list of denied memory regions. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Jan Beulich jbeul...@suse.com Cc: Andrew Cooper andrew.coop...@citrix.com Apologies that this reply is split between patch 0 and 2 - I replied to your cover letter before reading this patch. Denying access is only valid if acpi_table_hpet.flags ACPI_HPET_PAGE_PROTECT4 is true. Having just checked (as an example) the most modern Intel box I have direct access to, I wonder how many systems actually supply other than 0 here. Perhaps we ought to at once add a command line option to trigger the denial? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Cache Allocation Technology(CAT) design for XEN
At 14:09 +0800 on 19 Dec (1418994579), Chao Peng wrote: On Thu, Dec 18, 2014 at 05:40:28PM +0100, Tim Deegan wrote: Hi, Thanks for posting this - it's very useful. I have a couple of questions about the interface design. Thanks Tim. At 20:27 +0800 on 12 Dec (1418412477), Chao Peng wrote: Design Overview When enforcing cache allocation for VMs, the minimum granularity is defined as the domain. All Virtual CPUs (VCPUs) of a domain have the same COS, and therefore, correspond to the same CBM. COS is used only in hypervisor and is transparent to tool stack/user. System administrator can specify the initial CBM for each domain or change it at runtime using tool stack. Hypervisor then choses a free COS to associate it with that CBM or find a existed COS which has the same CBM. What happens if there is no existing COS that matches, and all COSes are in use? Does Xen return an error? Or try to change COS-CMB mappings during context switches? In the initial implementation, error is returned. It??s possible for hypervisor to share COS for different CBMes and not to return error here. But the problem is that COS shortage may still happen during context switch. At that time we will have no idea for what to do. So I??d prefer to return error directly here and leave the decision to user space, e.g. if error is returned then it can clear CBM for some domain and get free COS. Righto, thanks. Is it OK to assume that in the common case all CPUs have the same CAT capabilities? Then Xen can just report the smallest set of capabilities of any socket in the system, and the toolstack doesn't have to mess about with per-socket settings. I guess you can add that syntactic sugar on the tools if you want and leave the more powerful hypecall interface in case it's useful. :) Agreed, this is what I want to do. Basically the socketId is optional for the caller. If more than one socket exists, omitting socketId means the specified CBM applied to all sockets. While we still maintain per-socket CBM in hypervisor internally and provide per-socket hypercall interface in case it??s needed. In this way the interface should be user friendly for most cases. Sounds good. Thanks for clarifying. Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 2/2] Testing cpupools: recipe for it and job definition
On Thu, 2014-12-18 at 18:29 +0100, Dario Faggioli wrote: On Thu, 2014-12-18 at 16:10 +0100, Juergen Gross wrote: So: Why can't you test cpupools on ARM? We certainly can. ARM testing via OSSTest is a still experimental, AFAIUI. arm32 testing is production in osstest. I don't even know if we have the hardware, yet, as I think the rack of ARM dev board IanC was working on will be setup in the new testing COLO, rather than in current OSSTest pool of hardware (someone correct me if I'm wrong). The new rack is to replace the existing h/w used in production, since that can't be shipped to the colo for various reasons. However, that seems to be taken into account by the fact that, in make-flight, in test_matrix_do_one(), after only 2 jobs are created (the basic debian one and a libvirt one) we have this: # No further arm tests at the moment if [ $dom0arch = armhf ]; then return fi So, yes, I guess I can get rid of such filters in my new function, so that, when ARM maintainers will disable the safety catch above, a job will actually be generated. We should probably move some of the tests from below the cut to above already, e.g. do_sedf_tests and do_credit2_tests aren't arch specific, so should be run on arm. That's not your problem, but if you could add the new test above the cut that would be great. I'll sort out the other ones at some point. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RMRR Fix Design for Xen
Il 19/12/2014 02:21, Tiejun Chen ha scritto: RMRR Fix Design for Xen This design is a goal to fix RMRR for Xen. It includes four sectors as follows: * Background * What is RMRR * Current RMRR Issues * Design Overview We hope this can help us to understand current problem then figure out a clean and better solution everyone can agree now to go forward. Background == We first identified this RMRR defect when trying to pass-through IGD device, which can be simply fixed by adding an identity mapping in case of shared EPT table. However along with the community discussion, it boiled down to a more general RMRR problem, i.e. the identity mapping is brute-added in hypervisor, w/o considering whether conflicting with an existing guest PFN ranges. As a general solution we need invent a new mechanism so reserved ranges allocated by hypervisor can be exported to the user space toolstack and hvmloader, so conflict can be detected when constructing guest PFN layout, with best-effort avoidance policies to further help. What is RMRR RMRR is a acronym for Reserved Memory Region Reporting. BIOS may report each such reserved memory region through the RMRR structures, along with the devices that requires access to the specified reserved memory region. Reserved memory ranges that are either not DMA targets, or memory ranges that may be target of BIOS initiated DMA only during pre-boot phase (such as from a boot disk drive) must not be included in the reserved memory region reporting. The base address of each RMRR region must be 4KB aligned and the size must be an integer multiple of 4KB. BIOS must report the RMRR reported memory addresses as reserved in the system memory map returned through methods suchas INT15, EFI GetMemoryMap etc. The reserved memory region reporting structures are optional. If there are no RMRR structures, the system software concludes that the platform does not have any reserved memory ranges that are DMA targets. The RMRR regions are expected to be used for legacy usages (such as USB, UMA Graphics, etc.) requiring reserved memory. Platform designers shouldavoid or limit use of reserved memory regions since these require system software to create holes in the DMA virtual address range available to system software and its drivers. The following is grabbed from my BDW: (XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR: (XEN) [VT-D]dmar.c:679: RMRR region: base_addr ab80a000 end_address ab81dfff (XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR: (XEN) [VT-D]dmar.c:679: RMRR region: base_addr ad00 end_address af7f Here USB occupies 0xab80a000:0xab81dfff, IGD owns 0xad00:0xaf7f. Note there are zero or more Reserved Memory Region Reporting (RMRR) in one given platform. And multiple devices may share one RMRR range. Additionally RMRR can go anyplace. Current RMRR Issues === #1 RMRR may conflict RAM, mmio or other ranges in Guest physical level. Sorry if my question is not inherent, I don't have good knowledge about it, xen domUs require that all memory regions is correctly defined in hvmloader or do them automatically and correct in any emulated devices assigned to domUs? I'm unable to have qxl vga working in linux domUs and unable to found the problem for now, I saw a memory warning in system logs of domU with qxl which makes me think that perhaps the differences in memory regions of qxl are not considered properly in hvmloader. The warning I found in one Fedora domU with qxl is: ioremap error for 0xfc001000-0xfc002000, requested 0x10, got 0x0 Here a post about with logs compared also with stdvga tests and kvm (with qxl full working) test: http://lists.xen.org/archives/html/xen-devel/2013-10/msg00016.html Here the qxl support for libxl patch updated to latest xen if someone want fast try it: https://github.com/Fantu/Xen/commit/fadecf8d6ee0e8c7e421fafba67aa11879e8b8fe Can someone tell me is can be a hvmloader memory problem or this is not related? Thanks for any reply and sorry for my bad english. #2 Xen doesn't create RMRR mapping in case of shared ept, then the assigned device can't work well. #3 Xen doesn't consider that case multiple devices may share one RMRR entry. This also is a damage between different VMs when we assign such devices to different VMs. #4 Something like USB, is still restricted to current RMRR implementation. We should work out this case. Design Overview === First of all we need to make sure all resources don't overlap RMRR. And then in case of shared ept, we can set these identity entries. And Certainly we will group all devices associated to one same RMRR entry, then make sure all group devices should be assigned to same VM. 1. Setup RMRR identity mapping current status: * identity mapping only setup in non-shared ept case proposal: In non-shared ept case, IOMMU stuff always set those entries and RMRR is already marked
[Xen-devel] (no subject)
i got daily patch emails from xen-devel but i don't need on this email address so how to deactivate it please tell me___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] (no subject)
On Fri, 2014-12-19 at 17:53 +0800, Minalkumar Patel wrote: i got daily patch emails from xen-devel but i don't need on this email address so how to deactivate it please tell me Please visit http://lists.xen.org/cgi-bin/mailman/options/xen-devel Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Parallel make supported?
On Thu, 2014-12-18 at 22:36 +, Peter Kay wrote: Is parallel make supported for xen? If I compile 4.5 rc4 (although the error exists with many other prior releases too) with make -j4 world it fails part way through with an error 2. This does not occur with a straight 'make world' It is expected to work in general, I build with -j12 all the time. There are some subdirs which enforce serialised build for various reasons, perhaps there is one more we've not spotted or perhaps there is just a bug in the Makefiles somewhere. Please post your build logs showing the error. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Xen 4.5-rc] remus-drbd incompatible with Linux 3.6+ headers
Thank you for your response, I compiled Linux 3.0.101, sch_plug, and reinstalled remus-drbd. I still receive the same error when starting remus: xc: error: rdexact failed (select returned 0): Internal error xc: error: Error when reading batch size (110 = Connection timed out): Internal error xc: error: error when buffering batch, finishing (110 = Connection timed out): Internal error The error occurs at an earlier plug/unplug with faster intervals. I detailed my installation steps on my crude blog I just made, hopefully it helps: http://akorzan.com/dokuwiki/doku.php?id=xen:installation For Linux I used 3.4 or 3.0 and added the necessary options in make menuconfig. For 3.0 I had to get a separate copy of sch_plug. The only thing I had to differentiate from, is that for the DomU config, I had to use [phy:/dev/drbd1,w,xvda] instead of [drbd:ubuntu_vm_1,w,xvda] On a side note: Interestingly, after changing the Kernel from 3.4 to 3.0 and installing an external version of sch_plug, provided on the Xen Wiki, pings to the DomU don't display the delay the network buffering causes, but on longer intervals you can feel the extra time the pings take to respond. Weird. Many Thanks, Anthony On Dec 18, 2014, at 9:09 PM, Hongyang Yang yan...@cn.fujitsu.com wrote: Hi, 在 12/19/2014 05:48 AM, Anthony Korzan 写道: Hello! I have only managed to get Xen 4.5's Remus working on Linux Kernels less than 3.5. The provided remus-drbd, as detailed in docs/README.remus and available from https://github.com/rshriram/remus-drbd will not compile with Linux Kernels 3.6 and above. The DRBD you get from https://github.com/rshriram/remus-drbd is DRBD 8.3.11 and this version only compatible with Linux 3.0~3.4, see the table on this page: http://www.drbd.org/download/mainline/ I'm afraid DRBD 8.3.11 is the only version that you can get Remus work on currently. In the past, Remus disk replication based on blktap2, but blktap2 is getting deprecated I think, there's no maintainers nor patches recent years. If you are interest, there's a new FT solution based on Remus: http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping This solution use blktap2 as disk replication, and it has lots of patches to get blktap2 work with xl. Futhermore, we are working on a better solution on disk replication on both Remus/COLO. COLO is supposed to get into Xen 4.6. One of these errors is that remus-drbd uses a two argument version of the macro kunmap_atomic found in include/linux/highmem.h This was deprecated and is no longer included in any Kernels above 3.6. error: macro kunmap_atomic passed 2 arguments, but takes just 1 Is there a patch available? If not, what set up do the Remus devs use to test? I just need a stable-ish platform to modify remus on. Now I did get Remus working on Linux 3.4, Ubuntu 14.04, and the custom remus-drbd. The issue I run into is that Remus only plugs and unplugs a few hundred times until there is a Connection timeout error. It could be that I am using an old linux kernel version without much Xen integration, but I'm stumped about this error: Can you try to use Linux 3.0 to see if the error still exists? I will take a look on this problem to see if I can reproduce it. ### ... xc: progress: Reloading memory pages: 895015/65536 1365% xc: Saving memory: iter 1416 (last sent 568 skipped 0): 65536/65536 100% ... xc: Saving memory: iter 1420 (last sent 567 skipped 0): 65536/65536 100% xc: error: rdexact failed (select returned 0): Internal error xc: error: Error when reading batch size (110 = Connection timed out): Internal error xc: error: error when buffering batch, finishing (110 = Connection timed out): Internal error migration target: Remus Failover for domain 5 libxl: error: libxl_utils.c:430:libxl_read_exactly: file/stream truncated reading ipc msg header from domain 5 save/restore helper stdout pipe libxl: error: libxl_exec.c:129:libxl_report_child_exitstatus: domain 5 save/restore helper [-1] died due to fatal signal Broken pipe libxl: warning: libxl_dom.c:2015:domain_suspend_done: Remus: Domain suspend terminated with rc -3, teardown Remus devices... Remus: Backup failed? resuming domain at primary. xc: error: Dom 5 not suspended: (shutdown 0, reason 255): Internal error libxl: error: libxl.c:505:libxl__domain_resume: xc_domain_resume failed for domain 5: Invalid argument ### Sincerely, Anthony -- Thanks, Yang. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC V9 2/4] domain snapshot overview
On Thu, 2014-12-18 at 22:45 -0700, Chun Yan Liu wrote: On 12/18/2014 at 11:10 PM, in message 1418915443.11882.86.ca...@citrix.com, Ian Campbell ian.campb...@citrix.com wrote: On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote: Changes to V8: * add an overview document, so that one can has a overall look about the whole domain snapshot work, limits, requirements, how to do, etc. = Domain snapshot overview I don't see a similar section for disk snapshots, are you not considering those here except as a part of a domain snapshot or is this an oversight? There are three main use cases (that I know of at least) for snapshotting like behaviour. One is as you've mentioned below for backup, i.e. to preserve the VM at a certain point in time in order to be able to roll back to it. Is this the only usecase you are considering? Yes. I didn't take disk snapshot thing into the scope. A second use case is to support gold image type deployments, i.e. where you create one baseline single disk image and then clone it multiple times to deploy lots of guests. I think this is usually a disk snapshot type thing, but maybe it can be implemented as restoring a gold domain snapshot multiple times (e.g. for start of day performance reasons). As we initially discussed about the thing, disk snapshot thing can be done be existing tools directly like qemu-img, vhd-util. I was reading this section as a more generic overview of snapshotting, without reference to where/how things might ultimately be implemented. From a design point of view it would be useful to cover the various use cases, even if the solution is that the user implements them using CLI tools by hand (xl) or the toolstack does it for them internally (libvirt). This way we can more clearly see the full picture, which allows us to validate that we are making the right choices about what goes where. The third case, (which is similar to the first), is taking a disk snapshot in order to be able to run you usual backup software on the snapshot (which is now unchanging, which is handy) and then deleting the disk snapshot (this differs from the first case in which disk is active after the snapshot, and due to the lack of the memory part). Sorry, I'm still not quite clear about what this user case wants to do. The user has an active domain which they want to backup, but backup software often does not cope well if the data is changing under its feet. So the userswants to take a snapshot of the domains disks while leaving the domain running, so they can backup that static version of the disk out of band from the VM itself (e.g. by attaching it to a separate backup VM). This may require a guest agent to quiesce the disks. * ability to parse user config file [2] Disk snapshot requirements: - external tools: qemu-img, lvcreate, vhd-util, etc. - for basic goal, we support 'raw' and 'qcow2' backend types only. Then it requires: libxl qmp command or qemu-img (when qemu process does not exist) 3. Interaction with other operations: No. What about shutdown/dying as you noted above? What about migration or regular save/restore? Since xl now has no idea of the existence of snapshot, what about libvirt? This section is an overview, so making toolstack specific assumptions is confusing. so when writing this document I turned to depends on users to delete snapshots before or after deleting a domain (like shutdown, destroy, save, migrate away). User should know where memory is saved, and disk snapshot related info. What I meant was what happens if you try to snapshot a domain while it is being shutdown or being migrated? There clearly has to be some sort of interaction, even if it is there is a global toolstack lock or the user is advised not to do this. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl
On Fri, 2014-12-19 at 00:03 -0700, Chun Yan Liu wrote: '--name' meant to give a meaningful name (like: newinstall. Used as the memory snapshot name and disk snapshot name). Where is this name stored and when and where would it be presented to the user? That's good. Then we need to add some description to tell users about the auto-generated domain snapshot name, disk snapshot name, memory state file and external disk snapshot files, etc. We will need user docs and manpage updates, yes. #e.g. to specify exernal disk snapshot, like this: #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda', '/tmp/hdb_snapshot.qcow2,qcow2,hdb',] #e.g. to specify internal disk snapshot, like this: disks=[',,hda',',,hdb',] Ideally one or the other of these behaviours would be possible without needing to be quite so explicit. OK, I'll delete one. I don't object to having this more capable syntax as an option, so the user can override things if they wish, all I was suggesting is that the default ought to be something useful so the user doesn't need to say anything if they just want the toolstack to do something sensible. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu
On Thu, 2014-12-18 at 23:58 -0700, Chun Yan Liu wrote: On 12/18/2014 at 11:27 PM, in message 1418916436.11882.101.ca...@citrix.com, Ian Campbell ian.campb...@citrix.com wrote: On Tue, 2014-12-16 at 14:32 +0800, Chunyan Liu wrote: Changes to V8: * remove libxl_domain_snapshot_create/delete/revert API * export disk snapshot functionality for both xl and libvirt usage === Libxl/libxlu Design 1. New Structures libxl_disk_snapshot = Struct(disk_snapshot,[ # target disk (disk,libxl_device_disk), # disk snapshot name (name,string), # internal/external disk snapshot? (external,bool), # for external disk snapshot, specify following two field (external_format, string), (external_path, string), Should this be a KeyedUnion over a new LIBXL_DISK_SNAPSHOT_KIND enum (with values INTERNAL and EXTERNAL)? The KeyedUnion seems to be unnecessary. Only EXTERNAL has data items, INTERNAL doesn't, and no third types. This would automatically make the binding between external==true and the fields which depend on that. external_format should be of type libxl_disk_format, unless it is referring to something else? Yes. That's right. I'll update. Is it possible for format to differ from the format of the underlying disk? Perhaps taking a snapshot of a raw disk as a qcow? This is related to implementation details. As I understand qemu's implementation, taking an external disk snapshot is actually a way: origin domain disk: a raw disk external= true, external_format: qcow2, external_path: test a), create a qcow2 file (test.qcow2) with backing file (the raw disk) b), replace domain disk, now domain uses test.qcow2 (the raw disk is actually to be the snapshot) So, I think the external_format can only be those supporting backing file. Not sure what you mean here. What about a phy snapshot via lvm snapshotting? In any case passing in UNKNOWN and letting libxl choose (probably by picking the same as the underlying disk) should be supported. If external_format is not passed (NULL), by default, we will use qcow2. I think you need to base this on the type of the original disk, if it is e.g. vhd then making a qcow snapshot seems a bit odd. /* This API might not be used by xl, since xl won't take care of deleting * snapshots. But for libvirt, since libvirt manages snapshots and will * delete snapshot, this API will be used. */ int libxl_disk_snapshot_delete(libxl_ctx *ctx, uint32_t domid, libxl_disk_snapshot *snapshot, int nb); The three usecases I mentioned in the previous mail are important here, because depending on which usecases you are considering there maybe a many to one relationship between domains and a given snapshot (gold image case). This interface cannot support that I think. I'm not quite clear about the three usecases, especially the 3rd usercase, so really not sure what's the requirement towards deleting disk snapshot. I hope my reply to the previous mail helped clear this up a bit. The reason deleting a disk is interesting is because that is what you would do after the backup was finished. When we discussed this in previous iterations I suggested a libxl command to tell a VM that it needed to reexamine its disks to see if any of the chains had changed. I'm sure that's not the only potential answer though. About delete disk snapshot in a snapshot chain, whether we need to do extra work to avoid data break, it can be discussed: a). For external snapshots, usually it's based on backing file chain, qemu does this, vhd-util does this. In this case, to delete a domain snapshot, one doesn't need to do anything to disk (no need to delete disk snapshot at all). Downside is, there might be a long backing chain. I'm not sure what you mean here I'm afraid. If you are deleting a domain snapshot why do you not want to delete the disk snapshots associated with it? b). For internal snapshot, like qcow2, lvm too. For lvm, it doesn't support snapshot of snapshot, so out of scope. For qcow2, delete any disk snapshot won't affect others. For either internal or external if you are removing a snapshot from the middle of a chain which ends in one or more active disks, then surely the disk backend associated with those domains need to get some sort of notification, otherwise they would need to be written *very* carefully in order to be able to cope with disk metadata changing under their feet. Are you saying that the qemu/qcow implementation has indeed been written with this in mind and can cope with arbitrary other processes modifying the qcow metadata under their feet? e.g. BASE---SNAPSHOT A---SNAPSHOT B
Re: [Xen-devel] [OSSTEST PATCH 2/2] Testing cpupools: recipe for it and job definition
On Fri, 2014-12-19 at 09:48 +, Ian Campbell wrote: On Thu, 2014-12-18 at 18:29 +0100, Dario Faggioli wrote: On Thu, 2014-12-18 at 16:10 +0100, Juergen Gross wrote: So: Why can't you test cpupools on ARM? We certainly can. ARM testing via OSSTest is a still experimental, AFAIUI. arm32 testing is production in osstest. I don't even know if we have the hardware, yet, as I think the rack of ARM dev board IanC was working on will be setup in the new testing COLO, rather than in current OSSTest pool of hardware (someone correct me if I'm wrong). The new rack is to replace the existing h/w used in production, since that can't be shipped to the colo for various reasons. Ok. However, that seems to be taken into account by the fact that, in make-flight, in test_matrix_do_one(), after only 2 jobs are created (the basic debian one and a libvirt one) we have this: # No further arm tests at the moment if [ $dom0arch = armhf ]; then return fi So, yes, I guess I can get rid of such filters in my new function, so that, when ARM maintainers will disable the safety catch above, a job will actually be generated. We should probably move some of the tests from below the cut to above already, e.g. do_sedf_tests and do_credit2_tests aren't arch specific, so should be run on arm. I see. Great. :-) Scheduler testing being below the cutoff was exactly what made me thinking that we only wanted basic ARM testing for now, given the limited HW resources, and to keep the noise low. I'll certainly move this one below it. That's not your problem, but if you could add the new test above the cut that would be great. I'll sort out the other ones at some point. Sure I will. Thanks and Regards, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 2/2] Testing cpupools: recipe for it and job definition
On Fri, 2014-12-19 at 11:50 +0100, Dario Faggioli wrote: However, that seems to be taken into account by the fact that, in make-flight, in test_matrix_do_one(), after only 2 jobs are created (the basic debian one and a libvirt one) we have this: # No further arm tests at the moment if [ $dom0arch = armhf ]; then return fi So, yes, I guess I can get rid of such filters in my new function, so that, when ARM maintainers will disable the safety catch above, a job will actually be generated. We should probably move some of the tests from below the cut to above already, e.g. do_sedf_tests and do_credit2_tests aren't arch specific, so should be run on arm. I see. Great. :-) Scheduler testing being below the cutoff was exactly what made me thinking that we only wanted basic ARM testing for now, given the limited HW resources, and to keep the noise low Actually if anything we are underutilising the ARM resources we have, they usually finish way in advance of all the x86 stuff. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] EFI: suppress bogus loader warning
This was accidentally lost in commit fbc3d9a220 (EFI: add
efi_arch_handle_cmdline() for processing commandline), leading to the
Unknown command line option warning being printed whenever options
get passed to the core hypervisor or the Dom0 kernel.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -311,6 +311,7 @@ static unsigned int __init get_argv(unsi
++argc;
else if ( prev wstrcmp(prev, L--) == 0 )
{
+--argv;
if ( options )
*options = cmdline;
break;
EFI: suppress bogus loader warning
This was accidentally lost in commit fbc3d9a220 (EFI: add
efi_arch_handle_cmdline() for processing commandline), leading to the
Unknown command line option warning being printed whenever options
get passed to the core hypervisor or the Dom0 kernel.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -311,6 +311,7 @@ static unsigned int __init get_argv(unsi
++argc;
else if ( prev wstrcmp(prev, L--) == 0 )
{
+--argv;
if ( options )
*options = cmdline;
break;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] VT-d: don't crash when PTE bits 52 and up are non-zero
This can (and will) be legitimately the case when sharing page tables
with EPT (more of a problem before p2m_access_rwx became zero, but
still possible even now when other than that is the default for a
guest), leading to an unconditional crash (in print_vtd_entries())
when a DMA remapping fault occurs.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
Regarding the release, if the changes to iommu.c are deemed too
extensive, then _I think_ they could be split off (that code ought to
come into play only when not sharing page tables between VT-d and EPT,
and VT-d code never sets the offending bits to non-zero values afaict).
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -258,8 +258,7 @@ static u64 addr_to_dma_page_maddr(struct
struct dma_pte *parent, *pte = NULL;
int level = agaw_to_level(hd-arch.agaw);
int offset;
-u64 pte_maddr = 0, maddr;
-u64 *vaddr = NULL;
+u64 pte_maddr = 0;
addr = (((u64)1) addr_width) - 1;
ASSERT(spin_is_locked(hd-arch.mapping_lock));
@@ -281,19 +280,19 @@ static u64 addr_to_dma_page_maddr(struct
offset = address_level_offset(addr, level);
pte = parent[offset];
-if ( dma_pte_addr(*pte) == 0 )
+pte_maddr = dma_pte_addr(*pte);
+if ( !pte_maddr )
{
if ( !alloc )
break;
pdev = pci_get_pdev_by_domain(domain, -1, -1, -1);
drhd = acpi_find_matched_drhd_unit(pdev);
-maddr = alloc_pgtable_maddr(drhd, 1);
-if ( !maddr )
+pte_maddr = alloc_pgtable_maddr(drhd, 1);
+if ( !pte_maddr )
break;
-dma_set_pte_addr(*pte, maddr);
-vaddr = map_vtd_domain_page(maddr);
+dma_set_pte_addr(*pte, pte_maddr);
/*
* high level table always sets r/w, last level
@@ -303,21 +302,12 @@ static u64 addr_to_dma_page_maddr(struct
dma_set_pte_writable(*pte);
iommu_flush_cache_entry(pte, sizeof(struct dma_pte));
}
-else
-{
-vaddr = map_vtd_domain_page(pte-val);
-}
if ( level == 2 )
-{
-pte_maddr = pte-val PAGE_MASK_4K;
-unmap_vtd_domain_page(vaddr);
break;
-}
unmap_vtd_domain_page(parent);
-parent = (struct dma_pte *)vaddr;
-vaddr = NULL;
+parent = map_vtd_domain_page(pte_maddr);
level--;
}
@@ -2449,7 +2439,7 @@ static void vtd_dump_p2m_table_level(pad
printk(%*sgfn: %08lx mfn: %08lx\n,
indent, ,
(unsigned long)(address PAGE_SHIFT_4K),
- (unsigned long)(pte-val PAGE_SHIFT_4K));
+ (unsigned long)(dma_pte_addr(*pte) PAGE_SHIFT_4K));
}
unmap_vtd_domain_page(pt_vaddr);
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -276,7 +276,7 @@ struct dma_pte {
#define dma_set_pte_snp(p) do {(p).val |= DMA_PTE_SNP;} while(0)
#define dma_set_pte_prot(p, prot) \
do {(p).val = ((p).val ~3) | ((prot) 3); } while (0)
-#define dma_pte_addr(p) ((p).val PAGE_MASK_4K)
+#define dma_pte_addr(p) ((p).val PADDR_MASK PAGE_MASK_4K)
#define dma_set_pte_addr(p, addr) do {\
(p).val |= ((addr) PAGE_MASK_4K); } while (0)
#define dma_pte_present(p) (((p).val 3) != 0)
--- a/xen/drivers/passthrough/vtd/utils.c
+++ b/xen/drivers/passthrough/vtd/utils.c
@@ -170,16 +170,16 @@ void print_vtd_entries(struct iommu *iom
l_index = get_level_index(gmfn, level);
printk(l%d_index = %x\n, level, l_index);
-pte.val = val = l[l_index];
+pte.val = l[l_index];
unmap_vtd_domain_page(l);
-printk(l%d[%x] = %PRIx64\n, level, l_index, val);
+printk(l%d[%x] = %PRIx64\n, level, l_index, pte.val);
-pte.val = val;
if ( !dma_pte_present(pte) )
{
printk(l%d[%x] not present\n, level, l_index);
break;
}
+val = dma_pte_addr(pte);
} while ( --level );
}
VT-d: don't crash when PTE bits 52 and up are non-zero
This can (and will) be legitimately the case when sharing page tables
with EPT (more of a problem before p2m_access_rwx became zero, but
still possible even now when other than that is the default for a
guest), leading to an unconditional crash (in print_vtd_entries())
when a DMA remapping fault occurs.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
Regarding the release, if the changes to iommu.c are deemed too
extensive, then _I think_ they could be split off (that code ought to
come into play only when not sharing page tables between VT-d and EPT,
and VT-d code never sets the offending bits to non-zero values afaict).
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -258,8 +258,7 @@ static u64
Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET from Dom0
On 19/12/14 08:04, Roger Pau Monné wrote: Hello, El 18/12/14 a les 19.51, Andrew Cooper ha escrit: On 18/12/14 18:27, Roger Pau Monne wrote: Prevent Dom0 from accessing HPET MMIO region by adding it to the list of denied memory regions. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Jan Beulich jbeul...@suse.com Cc: Andrew Cooper andrew.coop...@citrix.com Apologies that this reply is split between patch 0 and 2 - I replied to your cover letter before reading this patch. Denying access is only valid if acpi_table_hpet.flags ACPI_HPET_PAGE_PROTECT4 is true. Thanks, if ACPI_HPET_PAGE_PROTECT4 is set then we can prevent access to the full page and if ACPI_HPET_PAGE_PROTECT64 is set we can prevent access to this page and the adjacent 60KB (15 pages). Will send an updated version. Roger. ACPI_HPET_PAGE_PROTECT64 stems from ia64 land, where pages can be 64k. I believe it can safely be ignored for x86, or perhaps used to imply ACPI_HPET_PAGE_PROTECT4 ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 6/7] tools/hotplug: remove EnvironmentFile from xen-qemu-dom0-disk-backend.service
The references Environment file does not exist, and the service file does not make use of variables anyway. Signed-off-by: Olaf Hering o...@aepfle.de Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com --- tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in index 0a5807a..274cec0 100644 --- a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in +++ b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in @@ -8,7 +8,6 @@ ConditionPathExists=/proc/xen/capabilities [Service] Type=simple -EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored PIDFile=@XEN_RUN_DIR@/qemu-dom0.pid ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities ExecStartPre=/bin/mkdir -p @XEN_RUN_DIR@ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 5/7] tools/hotplug: use XENCONSOLED_TRACE in xenconsoled.service
Instead of inventing a new XENCONSOLED_LOG= variable reuse the
existing XENCONSOLED_TRACE= variable in xenconsoled.service.
Signed-off-by: Olaf Hering o...@aepfle.de
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
---
tools/hotplug/Linux/systemd/xenconsoled.service.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in
b/tools/hotplug/Linux/systemd/xenconsoled.service.in
index 74d0428..4788129 100644
--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -7,13 +7,13 @@ ConditionPathExists=/proc/xen/capabilities
[Service]
Type=simple
Environment=XENCONSOLED_ARGS=
-Environment=XENCONSOLED_LOG=none
+Environment=XENCONSOLED_TRACE=none
Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
-ExecStart=@sbindir@/xenconsoled --pid-file @XEN_RUN_DIR@/xenconsoled.pid
--log=${XENCONSOLED_LOG} --log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
+ExecStart=@sbindir@/xenconsoled --pid-file @XEN_RUN_DIR@/xenconsoled.pid
--log=${XENCONSOLED_TRACE} --log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
[Install]
WantedBy=multi-user.target
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 4/7] tools/hotplug: use xencommons as EnvironmentFile in xenconsoled.service
The referenced sysconfig/xenconsoled does not exist. If anything
needs to be specified it has to go into the existing
sysconfig/xencommons file.
Signed-off-by: Olaf Hering o...@aepfle.de
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
---
tools/hotplug/Linux/systemd/xenconsoled.service.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in
b/tools/hotplug/Linux/systemd/xenconsoled.service.in
index cb44cd6..74d0428 100644
--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -9,7 +9,7 @@ Type=simple
Environment=XENCONSOLED_ARGS=
Environment=XENCONSOLED_LOG=none
Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
-EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenconsoled
+EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/7 v3] tools/hotplug: systemd changes for 4.5
This is a resend of these two series: http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00858.html http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html New in v3 is a wrapper to run xenstored. See its patch description for details. Patch 2-6 should be applied for 4.5.0. The first and the last one still has issues with xenstored and SELinux. See below. Up to now no solution is known to me. The first patch fixes Arch Linux and does not break anything. As such it should be safe to be applied for 4.5.0. SELinux users (who build from source) should put their special mount options into fstab. Distro packages will most likely include a proper .service file. The last patch addresses the XENSTORED_TRACE issue. But SELinux will most likely still not work. Possible ways to handle launching xenstored and SELinux: - do nothing pro: - no Xen source changes required con: - possible unhappy users who build from source and still have SELinux enabled - use newly added wrapper pro: - XENSTORED_TRACE boolean is handled con: - the wrapper may have the very same issue as the current launching with sh -c 'exec xenstored'. But maybe there is a way to mark the new wrapper script as this is the native xenstored. Someone familiar with SELinux may be able to answer this. - Use ExecStart=@XENSTORED@ pro: - socket passing will most likely work con: - All options have to be passed in XENSTORED_ARGS, a new variable which is not yet mentioned in the sysconfig file. - Switching xenstored requires a private copy of xenstored.service in /etc/systemd instead of adjusting the XENSTORED= variable in the sysconfig file. - Use ExecStart=/usr/bin/env $XENSTORED pro: - $XENSTORED can be set in sysconfig file con: - may have the same socket issue as starting via shell - XENSTORED_TRACE boolean is not handled I will be offline until 2015-01-07, so any further adjustments to this series has to be done by someone else. Good luck! Olaf Olaf Hering (7): tools/hotplug: remove SELinux options from var-lib-xenstored.mount tools/hotplug: remove XENSTORED_ROOTDIR from xenstored.service tools/hotplug: xendomains.service depends on network tools/hotplug: use xencommons as EnvironmentFile in xenconsoled.service tools/hotplug: use XENCONSOLED_TRACE in xenconsoled.service tools/hotplug: remove EnvironmentFile from xen-qemu-dom0-disk-backend.service tools/hotplug: add wrapper to start xenstored .gitignore| 1 + tools/configure | 3 ++- tools/configure.ac| 1 + tools/hotplug/Linux/Makefile | 2 ++ tools/hotplug/Linux/init.d/xencommons.in | 6 -- tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in| 4 +--- tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 - tools/hotplug/Linux/systemd/xenconsoled.service.in| 6 +++--- tools/hotplug/Linux/systemd/xendomains.service.in | 2 ++ tools/hotplug/Linux/systemd/xenstored.service.in | 6 ++ tools/hotplug/Linux/xenstored.sh.in | 6 ++ 11 files changed, 24 insertions(+), 14 deletions(-) create mode 100644 tools/hotplug/Linux/xenstored.sh.in ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3/7] tools/hotplug: xendomains.service depends on network
Starting domains during boot will most likely require network for the local bridge and it may need access to remote filesystems. Add ordering tags to systemd service file. Signed-off-by: Olaf Hering o...@aepfle.de Acked-by: Wei Liu wei.l...@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com --- tools/hotplug/Linux/systemd/xendomains.service.in | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/hotplug/Linux/systemd/xendomains.service.in b/tools/hotplug/Linux/systemd/xendomains.service.in index 9962671..66e2065 100644 --- a/tools/hotplug/Linux/systemd/xendomains.service.in +++ b/tools/hotplug/Linux/systemd/xendomains.service.in @@ -2,6 +2,8 @@ Description=Xendomains - start and stop guests on boot and shutdown Requires=proc-xen.mount xenstored.service After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service +After=network-online.target +After=remote-fs.target ConditionPathExists=/proc/xen/capabilities [Service] ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/7] tools/hotplug: remove SELinux options from var-lib-xenstored.mount
Using SELinux mount options per default breaks several systems. Either the context= mount option is not known at all to the kernel, as reported for ArchLinux. Or the default value none is unknown to SELinux, as reported for Fedora. In both cases the unit will fail. The proper place to specify mount options is /etc/fstab. Appearently systemd is kind enough to use values from there even if Options= or What= is specified in a .mount file. Remove XENSTORED_MOUNT_CTX, the reference to a non-existant EnvironmentFile and trim default Options= for the mount point. The removed code was first mentioned in the patch referenced below, with the following description: ... * Some systems define the selinux context in the systemd Option for the /var/lib/xenstored tmpfs: Options=mode=755,context=system_u:object_r:xenstored_var_lib_t:s0 For the upstream version we remove that and let systems specify the context on their system /etc/default/xenstored or /etc/sysconfig/xenstored $XENSTORED_MOUNT_CTX variable ... It is nowhere stated (on xen-devel) what Some systems means, which is unfortunately common practice in nearly all opensource projects. http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg02462.html Signed-off-by: Olaf Hering o...@aepfle.de Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com Cc: Anthony PERARD anthony.per...@citrix.com Cc: M A Young m.a.yo...@durham.ac.uk Cc: Luis R. Rodriguez mcg...@do-not-panic.com --- tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in index d5e04db..11a7d50 100644 --- a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in +++ b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in @@ -6,9 +6,7 @@ ConditionPathExists=/proc/xen/capabilities RefuseManualStop=true [Mount] -Environment=XENSTORED_MOUNT_CTX=none -EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenstored What=xenstore Where=@XEN_LIB_STORED@ Type=tmpfs -Options=mode=755,context=$XENSTORED_MOUNT_CTX +Options=mode=755 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/7] tools/hotplug: remove XENSTORED_ROOTDIR from xenstored.service
There is no need to export XENSTORED_ROOTDIR. This variable can be enabled in sysconfig/xencommons. If the variable is unset xenstored will automatically use @XEN_LIB_STORED@. Signed-off-by: Olaf Hering o...@aepfle.de Acked-by: Ian Jackson ian.jack...@eu.citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com --- tools/hotplug/Linux/systemd/xenstored.service.in | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in index 780bdd6..0f0ac58 100644 --- a/tools/hotplug/Linux/systemd/xenstored.service.in +++ b/tools/hotplug/Linux/systemd/xenstored.service.in @@ -9,7 +9,6 @@ ConditionPathExists=/proc/xen/capabilities [Service] Type=notify Environment=XENSTORED_ARGS= -Environment=XENSTORED_ROOTDIR=@XEN_LIB_STORED@ Environment=XENSTORED=@XENSTORED@ EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 7/7] tools/hotplug: add wrapper to start xenstored
The shell wrapper in xenstored.service does not handle XENSTORE_TRACE. Create a separate wrapper script which is used in the sysv runlevel script and in systemd xenstored.service. It preserves existing behaviour by handling the XENSTORE_TRACE boolean. It also implements the handling of XENSTORED_ARGS=. This variable has to be added to sysconfig/xencommons. The wrapper uses exec unconditionally. This works because the systemd service file passes --no-fork, which has the desired effect that the binary launched by systemd becomes the final daemon process. The sysv script does not pass --no-fork, which causes xenstored to fork internally to return to the caller of the wrapper script. The place of the wrapper is currently LIBEXEC_BIN, it has to be decided what the final location is supposed to be. IanJ wants it in /etc. Signed-off-by: Olaf Hering o...@aepfle.de Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com --- .gitignore | 1 + tools/configure | 3 ++- tools/configure.ac | 1 + tools/hotplug/Linux/Makefile | 2 ++ tools/hotplug/Linux/init.d/xencommons.in | 6 -- tools/hotplug/Linux/systemd/xenstored.service.in | 5 ++--- tools/hotplug/Linux/xenstored.sh.in | 6 ++ 7 files changed, 18 insertions(+), 6 deletions(-) diff --git a/.gitignore b/.gitignore index 8c8c06f..7e6884a 100644 --- a/.gitignore +++ b/.gitignore @@ -153,6 +153,7 @@ tools/hotplug/Linux/vif-setup tools/hotplug/Linux/xen-backend.rules tools/hotplug/Linux/xen-hotplug-common.sh tools/hotplug/Linux/xendomains +tools/hotplug/Linux/xenstored.sh tools/hotplug/NetBSD/rc.d/xencommons tools/include/xen/* tools/include/xen-foreign/*.(c|h|size) diff --git a/tools/configure b/tools/configure index b0aea0a..e72876c 100755 --- a/tools/configure +++ b/tools/configure @@ -2276,7 +2276,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu -ac_config_files=$ac_config_files ../config/Tools.mk hotplug/FreeBSD/rc.d/xencommons hotplug/Linux/init.d/sysconfig.xencommons hotplug/Linux/init.d/xen-watchdog hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains hotplug/Linux/systemd/proc-xen.mount hotplug/Linux/systemd/var-lib-xenstored.mount hotplug/Linux/systemd/xen-init-dom0.service hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service hotplug/Linux/systemd/xen-watchdog.service hotplug/Linux/systemd/xenconsoled.service hotplug/Linux/systemd/xendomains.service hotplug/Linux/systemd/xenstored.service hotplug/Linux/systemd/xenstored.socket hotplug/Linux/systemd/xenstored_ro.socket hotplug/Linux/vif-setup hotplug/Linux/xen-backend.rules hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains hotplug/NetBSD/rc.d/xencommons +ac_config_files=$ac_config_files ../config/Tools.mk hotplug/FreeBSD/rc.d/xencommons hotplug/Linux/init.d/sysconfig.xencommons hotplug/Linux/init.d/xen-watchdog hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains hotplug/Linux/systemd/proc-xen.mount hotplug/Linux/systemd/var-lib-xenstored.mount hotplug/Linux/systemd/xen-init-dom0.service hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service hotplug/Linux/systemd/xen-watchdog.service hotplug/Linux/systemd/xenconsoled.service hotplug/Linux/systemd/xendomains.service hotplug/Linux/systemd/xenstored.service hotplug/Linux/systemd/xenstored.socket hotplug/Linux/systemd/xenstored_ro.socket hotplug/Linux/vif-setup hotplug/Linux/xen-backend.rules hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains hotplug/Linux/xenstored.sh hotplug/NetBSD/rc.d/xencommons ac_config_headers=$ac_config_headers config.h @@ -9585,6 +9585,7 @@ do hotplug/Linux/xen-backend.rules) CONFIG_FILES=$CONFIG_FILES hotplug/Linux/xen-backend.rules ;; hotplug/Linux/xen-hotplug-common.sh) CONFIG_FILES=$CONFIG_FILES hotplug/Linux/xen-hotplug-common.sh ;; hotplug/Linux/xendomains) CONFIG_FILES=$CONFIG_FILES hotplug/Linux/xendomains ;; +hotplug/Linux/xenstored.sh) CONFIG_FILES=$CONFIG_FILES hotplug/Linux/xenstored.sh ;; hotplug/NetBSD/rc.d/xencommons) CONFIG_FILES=$CONFIG_FILES hotplug/NetBSD/rc.d/xencommons ;; config.h) CONFIG_HEADERS=$CONFIG_HEADERS config.h ;; diff --git a/tools/configure.ac b/tools/configure.ac index 1ac63a3..8f198e8 100644 --- a/tools/configure.ac +++ b/tools/configure.ac @@ -26,6 +26,7 @@ hotplug/Linux/vif-setup hotplug/Linux/xen-backend.rules hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains +hotplug/Linux/xenstored.sh hotplug/NetBSD/rc.d/xencommons ]) AC_CONFIG_HEADERS([config.h]) diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile index 1706c05..e9a1ef0 100644 --- a/tools/hotplug/Linux/Makefile +++ b/tools/hotplug/Linux/Makefile @@ -2,6 +2,7 @@ XEN_ROOT = $(CURDIR)/../../.. include
Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET from Dom0
On 19/12/14 09:11, Jan Beulich wrote: On 18.12.14 at 19:51, andrew.coop...@citrix.com wrote: On 18/12/14 18:27, Roger Pau Monne wrote: Prevent Dom0 from accessing HPET MMIO region by adding it to the list of denied memory regions. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Jan Beulich jbeul...@suse.com Cc: Andrew Cooper andrew.coop...@citrix.com Apologies that this reply is split between patch 0 and 2 - I replied to your cover letter before reading this patch. Denying access is only valid if acpi_table_hpet.flags ACPI_HPET_PAGE_PROTECT4 is true. Having just checked (as an example) the most modern Intel box I have direct access to, I wonder how many systems actually supply other than 0 here. Perhaps we ought to at once add a command line option to trigger the denial? I also can't find a server which sets this flag. I wonder how many systems actually have other things sitting in the remainder of the page. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Help: VMXNET3 support with XEN 4.4.1
Hello, In one of my experiment, I am building a Linux VM with Network interface model as vmxnet3. I am able to create the VM successfully, but I see that the driver loaded is vif and not vmxnet3. I am using the following option for the network interface: vif = [ 'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr0, model=vmxnet3' ] I tried with model as e1000 and it works fine. Lspci command also does not show vmxnet3. Though, qemu device help shows that vmxnet3 is supported on XEN 4.4.1 version I am using. I tried searching on internet about the right configuration for vmxnet3 with XEN, but not able to find right information. Can someone please help me on how to create a VM with vmxnet3? This experiment I am doing to compare the difference between vmxnet3 bandwidth on VMWARE ESXi vs. XEN Server. My sample VM configuration file is: # This configures an HVM rather than PV guest builder = hvm # Guest name name = rhel-vmxnet3-xen-2.hvm # 128-bit UUID for the domain as a hexadecimal number. # Use uuidgen to generate one if required. # The default behavior is to generate a new UUID each time the guest is started. #uuid = ---- # Enable Microsoft Hyper-V compatibile paravirtualisation / # enlightenment interfaces. Turning this on can improve Windows guest # performance and is therefore recommended #viridian = 1 # Initial memory allocation (MB) memory = 8192 # Maximum memory (MB) # If this is greater than `memory' then the slack will start ballooned # (this assumes guest kernel support for ballooning) #maxmem = 512 # Number of VCPUS vcpus = 8 # Network devices # A list of 'vifspec' entries as described in # docs/misc/xl-network-configuration.markdown vif = [ 'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr1, model=vmxnet3' ] # Disk Devices # A list of `diskspec' entries as described in # docs/misc/xl-disk-configuration.txt disk = [ '/root/rhel_6_4/rhel-vmxnet3-xen-2.img,raw,xvda,rw', 'file:/root/rhel-server-6.4-x86_64-dvd.iso,hdc:cdrom,r' ] boot='cd' # Guest VGA console configuration, either SDL or VNC # sdl = 1 vnc = 2 Thanks, -Upanshu Upanshu Singhal EMC Data Storage Systems, Bangalore, India. Phone: 91-80-67375604 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xenstored crashes with SIGSEGV
Hello Ian, On 18.12.2014 11:17, Ian Campbell wrote: On Tue, 2014-12-16 at 16:13 +, Frediano Ziglio wrote: Do we have a bug in Xen that affect SSE instructions (possibly already fixed after Philipp version) ? I've had a niggling feeling of Deja Vu over this which I'd been putting down to an old Xen on ARM bug in the area of FPU register switching. But it seems at some point (possibly even still) there was a similar issue with pvops kernels on x86, see: http://bugs.xenproject.org/xen/bug/40 That definitely looks interesting. Philipp, what kernel are you guys using? The crash 2014-12-06 01:26:21 xenstored[4337] happened on linux-3.10.46. That kernel is missing v3.10.50-13-gd1cc001: commit d1cc001905146d58c17ac8452eb96f226767819d Author: Silesh C V svella...@mvista.com Date: Wed Jul 23 13:59:59 2014 -0700 coredump: fix the setting of PF_DUMPCORE commit aed8adb7688d5744cb484226820163af31d2499a upstream. which explains why the xmm* registers are not included in the core file. I also can't quite shake the feeling that there was another much older issue relating to FPU context switch on x86, but I think that was truly ancient history (2.6.18 era stuff) Some of those host might still use 3.2, most use 3.10.x, but definitely no 2.6 kernels. Xen-Hypervisor is 4.1.3 If you need anything more, just ask. It might take me some time to answer as I'm on vacation for the next 2 weeks. Thanks again for your help. Philipp ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 32459: tolerable FAIL - PUSHED
flight 32459 qemu-mainline real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/32459/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32429 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-amd64-i386-libvirt 9 guest-start fail never pass test-armhf-armhf-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-amd64-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass version targeted for testing: qemuu86b182ac0e0b44726d85598cbefb468ed22517fc baseline version: qemuud86fb03469e016af4e54f04efccbc20a8afa3e19 People who touched revisions under test: Alexander Graf ag...@suse.de Antony Pavlov antonynpav...@gmail.com Leon Alrae leon.al...@imgtec.com Maciej W. Rozycki ma...@codesourcery.com Max Filippov jcmvb...@gmail.com Nathan Froyd froy...@codesourcery.com Peter Maydell peter.mayd...@linaro.org Sandra Loosemore san...@codesourcery.com Thomas Schwinge tho...@codesourcery.com jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64fail test-amd64-i386-xl-credit2 pass test-amd64-i386-freebsd10-i386 pass
Re: [Xen-devel] [PATCH v1 for-4.6 2/2] xen: prevent access to HPET from Dom0
On 19.12.14 at 12:32, andrew.coop...@citrix.com wrote: On 19/12/14 09:11, Jan Beulich wrote: On 18.12.14 at 19:51, andrew.coop...@citrix.com wrote: On 18/12/14 18:27, Roger Pau Monne wrote: Prevent Dom0 from accessing HPET MMIO region by adding it to the list of denied memory regions. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Jan Beulich jbeul...@suse.com Cc: Andrew Cooper andrew.coop...@citrix.com Apologies that this reply is split between patch 0 and 2 - I replied to your cover letter before reading this patch. Denying access is only valid if acpi_table_hpet.flags ACPI_HPET_PAGE_PROTECT4 is true. Having just checked (as an example) the most modern Intel box I have direct access to, I wonder how many systems actually supply other than 0 here. Perhaps we ought to at once add a command line option to trigger the denial? I also can't find a server which sets this flag. I wonder how many systems actually have other things sitting in the remainder of the page. One would think (or should I say hope) that there's at least nothing with read side effects anywhere, or else Linux'es exposing of the page to user mode would be a security problem. Perhaps we should also limit Dom0 mappings to r/o when we can't hide the page altogether. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Bisected Linux regression: ACPI powerbutton events don't work under Xen since commit b81975eade8c6495f3c4d6746d22bdc95f617777
Hi, When running under Xen, ACPI powerbutton events don't work anymore, there is no reaction when pressing the powerbutton. On baremetal everything works fine, acpid gets the event and the machine powers down perfectly. The machine is an Intel NUC. Bisection has lead to: b81975eade8c6495f3c4d6746d22bdc95f61 is the first bad commit commit b81975eade8c6495f3c4d6746d22bdc95f61 Author: Jiang Liu jiang@linux.intel.com Date: Mon Jun 9 16:20:11 2014 +0800 x86, irq: Clean up irqdomain transition code Now we have completely switched to irqdomain, so clean up transition code in IOAPIC drivers. Signed-off-by: Jiang Liu jiang@linux.intel.com Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com Cc: Tony Luck tony.l...@intel.com Cc: Joerg Roedel j...@8bytes.org Cc: Paul Gortmaker paul.gortma...@windriver.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Grant Likely grant.lik...@linaro.org Cc: Rafael J. Wysocki r...@rjwysocki.net Cc: Bjorn Helgaas bhelg...@google.com Cc: Randy Dunlap rdun...@infradead.org Cc: Yinghai Lu ying...@kernel.org Link: http://lkml.kernel.org/r/1402302011-23642-43-git-send-email-jiang@linux.intel.com Signed-off-by: Thomas Gleixner t...@linutronix.de Reverting this specific commit on linux-tip (3.19-mw) gets things working again under Xen. Kernel .config is attached. -- Sander dot-config Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Bisected Linux regression: ACPI powerbutton events don't work under Xen since commit b81975eade8c6495f3c4d6746d22bdc95f617777
Hi Sander, Sorry for the trouble, I will investigate on next Monday. Regards! Gerry On 2014/12/19 21:16, Sander Eikelenboom wrote: Hi, When running under Xen, ACPI powerbutton events don't work anymore, there is no reaction when pressing the powerbutton. On baremetal everything works fine, acpid gets the event and the machine powers down perfectly. The machine is an Intel NUC. Bisection has lead to: b81975eade8c6495f3c4d6746d22bdc95f61 is the first bad commit commit b81975eade8c6495f3c4d6746d22bdc95f61 Author: Jiang Liu jiang@linux.intel.com Date: Mon Jun 9 16:20:11 2014 +0800 x86, irq: Clean up irqdomain transition code Now we have completely switched to irqdomain, so clean up transition code in IOAPIC drivers. Signed-off-by: Jiang Liu jiang@linux.intel.com Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com Cc: Tony Luck tony.l...@intel.com Cc: Joerg Roedel j...@8bytes.org Cc: Paul Gortmaker paul.gortma...@windriver.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Grant Likely grant.lik...@linaro.org Cc: Rafael J. Wysocki r...@rjwysocki.net Cc: Bjorn Helgaas bhelg...@google.com Cc: Randy Dunlap rdun...@infradead.org Cc: Yinghai Lu ying...@kernel.org Link: http://lkml.kernel.org/r/1402302011-23642-43-git-send-email-jiang@linux.intel.com Signed-off-by: Thomas Gleixner t...@linutronix.de Reverting this specific commit on linux-tip (3.19-mw) gets things working again under Xen. Kernel .config is attached. -- Sander ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 for 4.5] x86/VPMU: Clear last_vcpu when destroying VPMU
On 18.12.14 at 19:06, boris.ostrov...@oracle.com wrote: We need to make sure that last_vcpu is not pointing to VCPU whose VPMU is being destroyed. Otherwise we may try to dereference it in the future, when VCPU is gone. We have to do this via IPI since otherwise there is a (somewheat theoretical) chance that between test and subsequent clearing of last_vcpu the remote processor (i.e. vpmu-last_pcpu) might do both vpmu_load() and then vpmu_save() for another VCPU. The former will clear last_vcpu and the latter will set it to something else. Performing this operation via IPI will guarantee that nothing can happen on the remote processor between testing and clearing of last_vcpu. We should also check for VPMU_CONTEXT_ALLOCATED in vpmu_destroy() to avoid unnecessary percpu tests and arch-specific destroy ops. Thus checks in AMD and Intel routines are no longer needed. Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com Acked-by: Jan Beulich jbeul...@suse.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Bisected Linux regression: ACPI powerbutton events don't work under Xen since commit b81975eade8c6495f3c4d6746d22bdc95f617777
Hi Sander,
Found the root cause now, but still need some time to find
a solution for this issue.
xen_smp_prepare_cpus() doesn't call:
smpboot_setup_io_apic()-setup_IO_APIC()
So no irqdomain structure for IOAPIC created, then mp_map_pin_to_irq()
fails at the very beginning.
The most simple solution is to revert following change, but it doesn't
seem the best solution. I will try to find a hook point to create
irqdomain for IOAPIC from xen_smp_prepare_cpus().
Regards!
Gerry
@@ -1034,13 +1035,8 @@ static int mp_map_pin_to_irq(u32 gsi, int idx,
int ioapic, int pin,
struct irq_domain *domain = mp_ioapic_irqdomain(ioapic);
struct mp_pin_info *info = mp_pin_info(ioapic, pin);
- if (!domain) {
- /*
-* Provide an identity mapping of gsi == irq except on truly
-* weird platforms that have non isa irqs in the first
16 gsis.
-*/
- return gsi = nr_legacy_irqs() ? gsi : gsi_top + gsi;
- }
+ if (!domain)
+ return -1;
mutex_lock(ioapic_mutex);
On 2014/12/19 21:16, Sander Eikelenboom wrote:
Hi,
When running under Xen, ACPI powerbutton events don't work anymore,
there is no reaction when pressing the powerbutton.
On baremetal everything works fine, acpid gets the event and the
machine powers down perfectly. The machine is an Intel NUC.
Bisection has lead to:
b81975eade8c6495f3c4d6746d22bdc95f61 is the first bad commit
commit b81975eade8c6495f3c4d6746d22bdc95f61
Author: Jiang Liu jiang@linux.intel.com
Date: Mon Jun 9 16:20:11 2014 +0800
x86, irq: Clean up irqdomain transition code
Now we have completely switched to irqdomain, so clean up transition code
in IOAPIC drivers.
Signed-off-by: Jiang Liu jiang@linux.intel.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Tony Luck tony.l...@intel.com
Cc: Joerg Roedel j...@8bytes.org
Cc: Paul Gortmaker paul.gortma...@windriver.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Randy Dunlap rdun...@infradead.org
Cc: Yinghai Lu ying...@kernel.org
Link:
http://lkml.kernel.org/r/1402302011-23642-43-git-send-email-jiang@linux.intel.com
Signed-off-by: Thomas Gleixner t...@linutronix.de
Reverting this specific commit on linux-tip (3.19-mw) gets things working
again under Xen.
Kernel .config is attached.
--
Sander
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] patch ping
Konrad, any word on http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01253.html http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01370.html http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01485.html sent several days ago (there were more earlier today) for 4.5? Thanks, Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] libxl memory leaks when Xen is compiled with XSM
Correctly CC'ing xen-devel as well this time ~Andrew On 19/12/14 14:31, Andrew Cooper wrote: Hello, Coverity has identified a large number of memory leaks in libxl, because of the use of libxl_domain_info() without an init/dispose for the libxl_dominfo object. If XSM is active, this leaks the ssid_label string, and in almost all cases, from the successful completion of the library function in question. Most of the issues can be fixed with the correct use of init()/dispose(), but libxl_wait_for_memory_target() is a little more interesting. Strictly speaking, I think I would need to fix it with a dispose();init() pair immediately before the call to libxl_domain_info(). However, this feels like overkill. As only the memory information is needed, would it be appropriate to downgrade to an xc_domain_getinfo() instead, forgoing the memory allocation and extraneous hypercalls? ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation Updates
Hi all,
in preparation for the release we need to update some wiki pages, as well as
in-tree docs
First of all, any new features for which any of you have written new wiki pages
should be marked with [[Category:Xen 4.5]]. Either do this, or reply with URLs
to pages and I will do so
Otherwise, I created boilerplate pages for various pages and tracked the status
on http://wiki.xenproject.org/wiki/Category:Xen_4.5
@Russell: you may want to update the XM to XL pages or create a new one and add
your video
== The following pages need to be reviewed and updated ==
* {{NotDone}} [[Linux PVH]]:
** Add PVH Dom0 information
** Review/correct the '''Things that are broken''' section
** Review/correct the '''Items that have not been tested extensively or at
all'''
* {{NotDone}} [[Xen ARM with Virtualization Extensions]]
** supported platforms need to be updated and
** all platforms that are supported in 4.5 tagged appropriately with
[[Category:Xen 4.5]]
== Lars will fix ==
* {{NotDone}} [[Xen Project 4.5 Acknowledgements]]
** Lars will do this.
* {{NotDone}} [[Xen Project 4.5 Feature List]]
** Lars will copy from the blog announcement when ready (Sarah is currently
making some final changes)
== For Konrad and others ==
* {{NotDone}} [[Xen Project Release Features]] - main 4.5 features need to be
added.
Please reply to the thread and I will add that page.
** The key changes normally are changes to scalability/memory/etc. limits -
maybe Jan(x86) and Ian(ARM) can look let me know of changes
** Also new platforms, changes to experimental features, etc.
** Probably the new scheduler should be added - is there a wiki page?
** Any other major new features that are worth highlighting? I can go through
the press release and the release note
* {{NotDone}} [[Xen Project 4.5 Release Notes]] - needs to be created
** http://wiki.xenproject.org/wiki/Xen_Project_4.4_Release_Notes were pretty
lightweight
** I think we should keep it that way. We should probably mainly focus on known
issues
@Konrad: what's your view?
== Missing pages ==
* {{NotDone}} [[Xen Project 4.5 Man Pages]]
** need to clone [[Xen Project 4.4 Man Pages]] and point to the correct branch
when the 4.5 branch has been created
** if there are new documented features in in-tree docs then add them
** if there are irrelevant features such as XM, remove links to docs (probably
the docs should be removed from the git tree also)
Cheers
Lars
On 16 Dec 2014, at 16:13, konrad.w...@oracle.com wrote:
Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then
we have the General Release on Jan 7th!
Details for the test-day are at
http://wiki.xen.org/wiki/Xen_4.5_RC4_test_instructions
In terms of bugs, we have:
#11 qxl hypervisor support
#13 Re: [Xen-devel] man page example: xm block-attach
#18 xl improve support for migration over non-sshlike tunnels
#19 xl migrate transport improvements
#22 xl does not support specifying virtual function for passthrough device
#23 Remove arbitrary LIBXL_MAXMEM_CONSTANT from libxl, see what breaks
#24 xl missing support for encrypted VNC
#27 Re: [Xen-devel] xend vs xl with pci=['bdf'] wherein the 'bdf' are not
owned by pciback or pcistub will still launch.
#28 support PCI hole resize in qemu-xen
[ 'mmio_hole' fix it, but the ultimate way is to fix it in QEMU]
#30 libxl should implement non-suspend-cancel based resume path
#36 credit2 only uses one runqueue instead of one runq per socket
#38 Implement VT-d large pages so we can avoid sharing between EPT
#40 linux pvops: fpu corruption due to incorrect assumptions
#42 linux, S3 resume of PVHVM fails - missing call to xen_arch_post_suspend?
#43 30s delay loading xenfb driver on some systems
#44 Security policy ambiguities - XSA-108 process post-mortem
#45 arm: domain 0 disables clocks which are in fact being used
#46 qemu-upstream: limitation on 4 emulated NICs prevents guest from starting
unless PV override is used.
= Timeline =
We wer planning on a 9-month release cycle - but it is more like an
10 month. Based on that, below are the estimated dates:
* Feature Freeze: 24th September 2014
* First RC: 24th October [Friday!]
* RC2: Nov 11th
* RC2 Test-day: Nov 13th
* RC3: Dec 3rd.
* RC3 Test-day: Dec 4th
* RC4: Dec 15th
WE ARE HERE ===
* RC4 Test-day: Dec 17th
Release Date: Jan 7th.
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
Re: [Xen-devel] Bisected Linux regression: ACPI powerbutton events don't work under Xen since commit b81975eade8c6495f3c4d6746d22bdc95f617777
Hi Sander,
Could you please help to test attached patch? It works
on native but I have no Xen environment at hand.
Thanks!
Gerry
On 2014/12/19 21:16, Sander Eikelenboom wrote:
Hi,
When running under Xen, ACPI powerbutton events don't work anymore,
there is no reaction when pressing the powerbutton.
On baremetal everything works fine, acpid gets the event and the
machine powers down perfectly. The machine is an Intel NUC.
Bisection has lead to:
b81975eade8c6495f3c4d6746d22bdc95f61 is the first bad commit
commit b81975eade8c6495f3c4d6746d22bdc95f61
Author: Jiang Liu jiang@linux.intel.com
Date: Mon Jun 9 16:20:11 2014 +0800
x86, irq: Clean up irqdomain transition code
Now we have completely switched to irqdomain, so clean up transition code
in IOAPIC drivers.
Signed-off-by: Jiang Liu jiang@linux.intel.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Tony Luck tony.l...@intel.com
Cc: Joerg Roedel j...@8bytes.org
Cc: Paul Gortmaker paul.gortma...@windriver.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Randy Dunlap rdun...@infradead.org
Cc: Yinghai Lu ying...@kernel.org
Link:
http://lkml.kernel.org/r/1402302011-23642-43-git-send-email-jiang@linux.intel.com
Signed-off-by: Thomas Gleixner t...@linutronix.de
Reverting this specific commit on linux-tip (3.19-mw) gets things working
again under Xen.
Kernel .config is attached.
--
Sander
From a6928b3c93a5119c79b8a7aec953579c87d2a4cc Mon Sep 17 00:00:00 2001
From: Jiang Liu jiang@linux.intel.com
Date: Fri, 19 Dec 2014 22:33:56 +0800
Subject: [PATCH] x86/apic: Fix xen failure caused by commit b81975eade8c
Commit b81975eade8c x86, irq: Clean up irqdomain transition code
breaks Xen because xen_smp_prepare_cpus() doesn't call setup_IO_APIC()
so mp_map_pin_to_irq() fails at the very beginning.
Signed-off-by: Jiang Liu jiang@linux.intel.com
---
arch/x86/include/asm/hw_irq.h|2 +-
arch/x86/include/asm/smpboot_hooks.h |6 +++---
arch/x86/kernel/apic/apic.c |6 +++---
arch/x86/kernel/apic/io_apic.c | 32 +++-
arch/x86/xen/smp.c |3 +++
5 files changed, 25 insertions(+), 24 deletions(-)
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index 4615906d83df..0c6530dfd817 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -98,7 +98,7 @@ extern void trace_call_function_single_interrupt(void);
#define IO_APIC_IRQ(x) (((x) = NR_IRQS_LEGACY) || ((1(x)) io_apic_irqs))
extern unsigned long io_apic_irqs;
-extern void setup_IO_APIC(void);
+extern void setup_IO_APIC(bool xen_smp);
extern void disable_IO_APIC(void);
struct io_apic_irq_attr {
diff --git a/arch/x86/include/asm/smpboot_hooks.h b/arch/x86/include/asm/smpboot_hooks.h
index 0da7409f0bec..76e5731b03cb 100644
--- a/arch/x86/include/asm/smpboot_hooks.h
+++ b/arch/x86/include/asm/smpboot_hooks.h
@@ -52,9 +52,9 @@ static inline void __init smpboot_setup_io_apic(void)
* Here we can be sure that there is an IO-APIC in the system. Let's
* go and set it up:
*/
- if (!skip_ioapic_setup nr_ioapics)
- setup_IO_APIC();
- else {
+ if (!skip_ioapic_setup nr_ioapics) {
+ setup_IO_APIC(false);
+ } else {
nr_ioapics = 0;
}
#endif
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index ba6cc041edb1..33ba1f97abea 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1912,9 +1912,9 @@ int __init APIC_init_uniprocessor(void)
bsp_end_local_APIC_setup();
#ifdef CONFIG_X86_IO_APIC
- if (smp_found_config !skip_ioapic_setup nr_ioapics)
- setup_IO_APIC();
- else {
+ if (smp_found_config !skip_ioapic_setup nr_ioapics) {
+ setup_IO_APIC(false);
+ } else {
nr_ioapics = 0;
}
#endif
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index a6745e756729..5879ac58c3b6 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2965,31 +2965,29 @@ static int mp_irqdomain_create(int ioapic)
return 0;
}
-void __init setup_IO_APIC(void)
+void __init setup_IO_APIC(bool xen_smp)
{
int ioapic;
- /*
- * calling enable_IO_APIC() is moved to setup_local_APIC for BP
- */
- io_apic_irqs = nr_legacy_irqs() ? ~PIC_IRQS : ~0UL;
+ if (!xen_smp) {
+ apic_printk(APIC_VERBOSE, ENABLING IO-APIC IRQs\n);
+ io_apic_irqs = nr_legacy_irqs() ? ~PIC_IRQS : ~0UL;
+
+ /* Set up IO-APIC IRQ routing. */
+ x86_init.mpparse.setup_ioapic_ids();
+ sync_Arb_IDs();
+ }
- apic_printk(APIC_VERBOSE, ENABLING IO-APIC IRQs\n);
for_each_ioapic(ioapic)
BUG_ON(mp_irqdomain_create(ioapic));
-
- /*
- * Set up IO-APIC IRQ routing.
- */
-
Re: [Xen-devel] Xen 4.5 Development Update (RC4)
On 16/12/14 20:49, Konrad Rzeszutek Wilk wrote: On Tue, Dec 16, 2014 at 05:43:08PM +, Andrew Cooper wrote: On 16/12/14 16:13, konrad.w...@oracle.com wrote: Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then we have the General Release on Jan 7th! Details for the test-day are at http://wiki.xen.org/wiki/Xen_4.5_RC4_test_instructions In terms of bugs, we have: From the XenServer testing. Thank you for doing this testing! * Fail to reliably boot on IBM Flex x222 blades, apparent regression from 4.4 I have declared this a latent BIOS bug, and not a regression from 4.4. Across regular reboots, the exact positions of the ACPI tables, and the e820 layout is unstable. The first consistent difference between 4.4 and 4.5 is that 4.4 reports 1 MBR signature while 4.5 reports 0. This is because the int $0x13, ah=2 call is returning differently. I can get the call to return differently (and correctly for 4.5) by simply making the boot trampoline larger (with my debugging routines but not being called). This sounds very familiar, but I can't place where I saw mention of a similar issue. * VM fail to resume on upgrade from Xen 4.5 This is the issue I am currently looking into. Currently, all the upgrade from older XenServer tests are failing due to VMs crashing on resume. I have not yet identified whether this is a XenServer issue or Ugh. I have got to the bottom of this, and it it turns out to be a legacy - migration v2 conversion bug which only surfaced now because Xen-4.5 is more strict than Xen-4.4. HVM_PARAM_PAE_ENABLED is sent out-of-band in legacy, but passed to xc_domain_restore(), which does a set_param(), unconnected with any contents of the stream. Migration v2 saves and restores it properly, but the legacy - v2 conversion neglected to combine the out-of-band information. No VMs blew up because all versions of Xen at that point were not correctly auditing updates to cr4 against the domain cpuid policy. Xen-4.5 now does, causing #GP faults on cr4 writes for guests which had PAE enabled before migrate. I shall be fixing this in the migration v2 series, and also looking for any other obvious out-of-band information which needs injecting into a converted stream. With this fixed(^W hacked around for now), I have identified and solved all discrepancies XenServer testing has noticed between Xen-4.4 and Xen-4.5 so far. There will be another full nightly test happening tonight (based on c/s 7e88c23 libxl: Tell qemu to use raw format when using a tapdisk), and some stress and scale tests if time allows. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation Updates
On 19.12.14 at 15:52, lars.kurth@gmail.com wrote: ** The key changes normally are changes to scalability/memory/etc. limits - maybe Jan(x86) and Ian(ARM) can look let me know of changes Iirc scalability changes on the x86 side were mostly (if not exclusively) in terms of performance improvements (in some cases getting bigger guests out of not booting at all state). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation Updates
Hi Lars, 2014-12-19 9:52 GMT-05:00 Lars Kurth lars.kurth@gmail.com: Hi all, Please reply to the thread and I will add that page. ** The key changes normally are changes to scalability/memory/etc. limits - maybe Jan(x86) and Ian(ARM) can look let me know of changes ** Also new platforms, changes to experimental features, etc. ** Probably the new scheduler should be added - is there a wiki page? The new scheduler (rtds) does not have a wiki page right now, but it has an outside page to explain how it is designed and how it works at https://sites.google.com/site/realtimexen/getting-started. I can add a wiki page very quickly today based on the pages on https://sites.google.com/site/realtimexen/ . Is that ok? Thanks, Meng -- --- 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.5 Development Update (RC4) - Documentation Updates
On 19 Dec 2014, at 15:55, Meng Xu xumengpa...@gmail.com wrote: Hi Lars, 2014-12-19 9:52 GMT-05:00 Lars Kurth lars.kurth@gmail.com: Hi all, Please reply to the thread and I will add that page. ** The key changes normally are changes to scalability/memory/etc. limits - maybe Jan(x86) and Ian(ARM) can look let me know of changes ** Also new platforms, changes to experimental features, etc. ** Probably the new scheduler should be added - is there a wiki page? The new scheduler (rtds) does not have a wiki page right now, but it has an outside page to explain how it is designed and how it works at https://sites.google.com/site/realtimexen/getting-started. I can add a wiki page very quickly today based on the pages on https://sites.google.com/site/realtimexen/ . Is that ok? That would be perfect. Lars___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] xen/x86: properly retrieve NMI reason
Using the native code here can't work properly, as the hypervisor would
normally have cleared the two reason bits by the time Dom0 gets to see
the NMI (if passed to it at all). There's a shared info field for this,
and there's an existing hook to use - just fit the two together. Note
that the hook can (and should) be used irrespective of whether being in
Dom0, as accessing port 0x61 in a DomU would be even worse, while the
shared info field would just hold zero all the time.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
arch/x86/xen/enlighten.c| 22 +-
include/xen/interface/nmi.h | 52
2 files changed, 73 insertions(+), 1 deletion(-)
--- 3.18/arch/x86/xen/enlighten.c
+++ 3.18-xen-x86-NMI-reason/arch/x86/xen/enlighten.c
@@ -40,6 +40,7 @@
#include xen/interface/physdev.h
#include xen/interface/vcpu.h
#include xen/interface/memory.h
+#include xen/interface/nmi.h
#include xen/interface/xen-mca.h
#include xen/features.h
#include xen/page.h
@@ -66,6 +67,7 @@
#include asm/reboot.h
#include asm/stackprotector.h
#include asm/hypervisor.h
+#include asm/mach_traps.h
#include asm/mwait.h
#include asm/pci_x86.h
#include asm/pat.h
@@ -1357,6 +1359,21 @@ static const struct machine_ops xen_mach
.emergency_restart = xen_emergency_restart,
};
+static unsigned char xen_get_nmi_reason(void)
+{
+ unsigned char reason = 0;
+
+ /* Construct a value which looks like it came from port 0x61. */
+ if (test_bit(_XEN_NMIREASON_io_error,
+HYPERVISOR_shared_info-arch.nmi_reason))
+ reason |= NMI_REASON_IOCHK;
+ if (test_bit(_XEN_NMIREASON_pci_serr,
+HYPERVISOR_shared_info-arch.nmi_reason))
+ reason |= NMI_REASON_SERR;
+
+ return reason;
+}
+
static void __init xen_boot_params_init_edd(void)
{
#if IS_ENABLED(CONFIG_EDD)
@@ -1541,9 +1558,12 @@ asmlinkage __visible void __init xen_sta
pv_info = xen_info;
pv_init_ops = xen_init_ops;
pv_apic_ops = xen_apic_ops;
- if (!xen_pvh_domain())
+ if (!xen_pvh_domain()) {
pv_cpu_ops = xen_cpu_ops;
+ x86_platform.get_nmi_reason = xen_get_nmi_reason;
+ }
+
if (xen_feature(XENFEAT_auto_translated_physmap))
x86_init.resources.memory_setup = xen_auto_xlated_memory_setup;
else
--- /usr/local/src/linux-3.18/include/xen/interface/nmi.h 1970-01-01
01:00:00.0 +0100
+++ 3.18-xen-x86-NMI-reason/include/xen/interface/nmi.h
@@ -0,0 +1,52 @@
+/**
+ * nmi.h
+ *
+ * NMI callback registration and reason codes.
+ *
+ * Copyright (c) 2005, Keir Fraser k...@xensource.com
+ */
+
+#ifndef __XEN_PUBLIC_NMI_H__
+#define __XEN_PUBLIC_NMI_H__
+
+#include xen/interface/xen.h
+
+/*
+ * NMI reason codes:
+ * Currently these are x86-specific, stored in arch_shared_info.nmi_reason.
+ */
+ /* I/O-check error reported via ISA port 0x61, bit 6. */
+#define _XEN_NMIREASON_io_error 0
+#define XEN_NMIREASON_io_error (1UL _XEN_NMIREASON_io_error)
+ /* PCI SERR reported via ISA port 0x61, bit 7. */
+#define _XEN_NMIREASON_pci_serr 1
+#define XEN_NMIREASON_pci_serr (1UL _XEN_NMIREASON_pci_serr)
+ /* Unknown hardware-generated NMI. */
+#define _XEN_NMIREASON_unknown 2
+#define XEN_NMIREASON_unknown (1UL _XEN_NMIREASON_unknown)
+
+/*
+ * long nmi_op(unsigned int cmd, void *arg)
+ * NB. All ops return zero on success, else a negative error code.
+ */
+
+/*
+ * Register NMI callback for this (calling) VCPU. Currently this only makes
+ * sense for domain 0, vcpu 0. All other callers will be returned EINVAL.
+ * arg == pointer to xennmi_callback structure.
+ */
+#define XENNMI_register_callback 0
+struct xennmi_callback {
+unsigned long handler_address;
+unsigned long pad;
+};
+typedef struct xennmi_callback xennmi_callback_t;
+DEFINE_XEN_GUEST_HANDLE(xennmi_callback_t);
+
+/*
+ * Deregister NMI callback for this (calling) VCPU.
+ * arg == NULL.
+ */
+#define XENNMI_unregister_callback 1
+
+#endif /* __XEN_PUBLIC_NMI_H__ */
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation Updates
On Fri, 2014-12-19 at 10:55 -0500, Meng Xu wrote: 2014-12-19 9:52 GMT-05:00 Lars Kurth lars.kurth@gmail.com: Hi all, Please reply to the thread and I will add that page. ** The key changes normally are changes to scalability/memory/etc. limits - maybe Jan(x86) and Ian(ARM) can look let me know of changes ** Also new platforms, changes to experimental features, etc. ** Probably the new scheduler should be added - is there a wiki page? The new scheduler (rtds) does not have a wiki page right now, but it has an outside page to explain how it is designed and how it works at https://sites.google.com/site/realtimexen/getting-started. I can add a wiki page very quickly today based on the pages on https://sites.google.com/site/realtimexen/ . That would be great! :-) Is that ok? I think it is ok. Just make sure, when you do that, that you properly adapt the information and make them match what actually have been upstreamed (so command option names, limits of the implementation, etc.) Also, you should put in the wiki page a WARN about the fact that the scheduler has been included as an experimental and in-development feature. Share here a link when you're done, so we can go having a look. :-) Thanks and Regards, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen/x86: properly retrieve NMI reason
On 12/19/2014 11:16 AM, Jan Beulich wrote:
Using the native code here can't work properly, as the hypervisor would
normally have cleared the two reason bits by the time Dom0 gets to see
the NMI (if passed to it at all). There's a shared info field for this,
and there's an existing hook to use - just fit the two together. Note
that the hook can (and should) be used irrespective of whether being in
Dom0, as accessing port 0x61 in a DomU would be even worse, while the
shared info field would just hold zero all the time.
Reviewed-by: Boris Ostrovsky boris.ostrov...@oracle.com
Signed-off-by: Jan Beulich jbeul...@suse.com
---
arch/x86/xen/enlighten.c| 22 +-
include/xen/interface/nmi.h | 52
2 files changed, 73 insertions(+), 1 deletion(-)
--- 3.18/arch/x86/xen/enlighten.c
+++ 3.18-xen-x86-NMI-reason/arch/x86/xen/enlighten.c
@@ -40,6 +40,7 @@
#include xen/interface/physdev.h
#include xen/interface/vcpu.h
#include xen/interface/memory.h
+#include xen/interface/nmi.h
#include xen/interface/xen-mca.h
#include xen/features.h
#include xen/page.h
@@ -66,6 +67,7 @@
#include asm/reboot.h
#include asm/stackprotector.h
#include asm/hypervisor.h
+#include asm/mach_traps.h
#include asm/mwait.h
#include asm/pci_x86.h
#include asm/pat.h
@@ -1357,6 +1359,21 @@ static const struct machine_ops xen_mach
.emergency_restart = xen_emergency_restart,
};
+static unsigned char xen_get_nmi_reason(void)
+{
+ unsigned char reason = 0;
+
+ /* Construct a value which looks like it came from port 0x61. */
+ if (test_bit(_XEN_NMIREASON_io_error,
+HYPERVISOR_shared_info-arch.nmi_reason))
+ reason |= NMI_REASON_IOCHK;
+ if (test_bit(_XEN_NMIREASON_pci_serr,
+HYPERVISOR_shared_info-arch.nmi_reason))
+ reason |= NMI_REASON_SERR;
+
+ return reason;
+}
+
static void __init xen_boot_params_init_edd(void)
{
#if IS_ENABLED(CONFIG_EDD)
@@ -1541,9 +1558,12 @@ asmlinkage __visible void __init xen_sta
pv_info = xen_info;
pv_init_ops = xen_init_ops;
pv_apic_ops = xen_apic_ops;
- if (!xen_pvh_domain())
+ if (!xen_pvh_domain()) {
pv_cpu_ops = xen_cpu_ops;
+ x86_platform.get_nmi_reason = xen_get_nmi_reason;
+ }
+
if (xen_feature(XENFEAT_auto_translated_physmap))
x86_init.resources.memory_setup = xen_auto_xlated_memory_setup;
else
--- /usr/local/src/linux-3.18/include/xen/interface/nmi.h 1970-01-01
01:00:00.0 +0100
+++ 3.18-xen-x86-NMI-reason/include/xen/interface/nmi.h
@@ -0,0 +1,52 @@
+/**
+ * nmi.h
+ *
+ * NMI callback registration and reason codes.
+ *
+ * Copyright (c) 2005, Keir Fraser k...@xensource.com
+ */
+
+#ifndef __XEN_PUBLIC_NMI_H__
+#define __XEN_PUBLIC_NMI_H__
+
+#include xen/interface/xen.h
+
+/*
+ * NMI reason codes:
+ * Currently these are x86-specific, stored in arch_shared_info.nmi_reason.
+ */
+ /* I/O-check error reported via ISA port 0x61, bit 6. */
+#define _XEN_NMIREASON_io_error 0
+#define XEN_NMIREASON_io_error (1UL _XEN_NMIREASON_io_error)
+ /* PCI SERR reported via ISA port 0x61, bit 7. */
+#define _XEN_NMIREASON_pci_serr 1
+#define XEN_NMIREASON_pci_serr (1UL _XEN_NMIREASON_pci_serr)
+ /* Unknown hardware-generated NMI. */
+#define _XEN_NMIREASON_unknown 2
+#define XEN_NMIREASON_unknown (1UL _XEN_NMIREASON_unknown)
+
+/*
+ * long nmi_op(unsigned int cmd, void *arg)
+ * NB. All ops return zero on success, else a negative error code.
+ */
+
+/*
+ * Register NMI callback for this (calling) VCPU. Currently this only makes
+ * sense for domain 0, vcpu 0. All other callers will be returned EINVAL.
+ * arg == pointer to xennmi_callback structure.
+ */
+#define XENNMI_register_callback 0
+struct xennmi_callback {
+unsigned long handler_address;
+unsigned long pad;
+};
+typedef struct xennmi_callback xennmi_callback_t;
+DEFINE_XEN_GUEST_HANDLE(xennmi_callback_t);
+
+/*
+ * Deregister NMI callback for this (calling) VCPU.
+ * arg == NULL.
+ */
+#define XENNMI_unregister_callback 1
+
+#endif /* __XEN_PUBLIC_NMI_H__ */
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation Updates
Hi Lars and Dario, 2014-12-19 11:15 GMT-05:00 Dario Faggioli dario.faggi...@citrix.com: On Fri, 2014-12-19 at 10:55 -0500, Meng Xu wrote: 2014-12-19 9:52 GMT-05:00 Lars Kurth lars.kurth@gmail.com: Hi all, Please reply to the thread and I will add that page. ** The key changes normally are changes to scalability/memory/etc. limits - maybe Jan(x86) and Ian(ARM) can look let me know of changes ** Also new platforms, changes to experimental features, etc. ** Probably the new scheduler should be added - is there a wiki page? The new scheduler (rtds) does not have a wiki page right now, but it has an outside page to explain how it is designed and how it works at https://sites.google.com/site/realtimexen/getting-started. I can add a wiki page very quickly today based on the pages on https://sites.google.com/site/realtimexen/ . That would be great! :-) Is that ok? I think it is ok. Just make sure, when you do that, that you properly adapt the information and make them match what actually have been upstreamed (so command option names, limits of the implementation, etc.) Also, you should put in the wiki page a WARN about the fact that the scheduler has been included as an experimental and in-development feature. Share here a link when you're done, so we can go having a look. :-) I have finished the wiki page. Here is the link: http://wiki.xenproject.org/wiki/User:Pennpanda I followed the Credit scheduler's wiki page to complete the RTDS'. (I'm not sure how to add a title for that page as Credit scheduler does. :-( ) Please let me know if you have any question. Thank you very much! :-) Best, Meng -- --- 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] [PATCH] libxc: check return values on mmap() and madvise() on xc_alloc_hypercall_buffer()
Please backport this patch to 4.4.
Other branches may need the mmap() check as well. The callers expect
either NULL or a valid pointer.
It is upstream commit e86539a388314cd3dca88f5e69d7873343197cd8
Thanks,
Olaf
On Wed, May 21, Ian Campbell wrote:
On Tue, 2014-05-20 at 05:37 -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
On a Thinkpad T4440p with OpenSUSE tumbleweed with v3.15-rc4
and today's latest xen tip from the git tree strace -f reveals
we end up on a never ending wait shortly after
write(20, backend/console/5\0, 18 unfinished ...
This is right before we just wait on the qemu process which we
had mmap'd for. Without this you'll end up getting stuck on a
loop if mmap() worked but madvise() did not. While at it I noticed
even the mmap() error fail was not being checked, fix that too.
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
Acked-by: Ian Campbell ian.campb...@citrix.com and applied.
OOI why was madvise failing? (should be quite unusual I think?)
---
tools/libxc/xc_linux_osdep.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
index 73860a2..86bff3e 100644
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -92,14 +92,32 @@ static void
*linux_privcmd_alloc_hypercall_buffer(xc_interface *xch, xc_osdep_ha
{
size_t size = npages * XC_PAGE_SIZE;
void *p;
+int rc, saved_errno;
/* Address returned by mmap is page aligned. */
p = mmap(NULL, size, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_LOCKED, -1, 0);
+if ( p == MAP_FAILED )
+{
+PERROR(xc_alloc_hypercall_buffer: mmap failed);
+return NULL;
+}
/* Do not copy the VMA to child process on fork. Avoid the page being
COW
on hypercall. */
-madvise(p, npages * XC_PAGE_SIZE, MADV_DONTFORK);
+rc = madvise(p, npages * XC_PAGE_SIZE, MADV_DONTFORK);
+if ( rc 0 )
+{
+PERROR(xc_alloc_hypercall_buffer: madvise failed);
+goto out;
+}
+
return p;
+
+out:
+saved_errno = errno;
+(void)munmap(p, size);
+errno = saved_errno;
+return NULL;
}
static void linux_privcmd_free_hypercall_buffer(xc_interface *xch,
xc_osdep_handle h, void *ptr, int npages)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation Updates
On 19 Dec 2014, at 17:10, Meng Xu xumengpa...@gmail.com wrote: I have finished the wiki page. Here is the link: http://wiki.xenproject.org/wiki/User:Pennpanda I followed the Credit scheduler's wiki page to complete the RTDS'. (I'm not sure how to add a title for that page as Credit scheduler does. :-( ) Please let me know if you have any question. Thank you Meng: I will move the content to a page called RTDS-Based-Scheduler of there are no objections Lars___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] patch ping
On Fri, Dec 19, 2014 at 01:48:18PM +, Jan Beulich wrote: Konrad, any word on http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01253.html Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01370.html Shouldn't that have Reported-by: Sander..? Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01485.html Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com sent several days ago (there were more earlier today) for 4.5? Thanks, Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] EFI: suppress bogus loader warning
On Fri, Dec 19, 2014 at 11:17:02AM +, Jan Beulich wrote:
This was accidentally lost in commit fbc3d9a220 (EFI: add
efi_arch_handle_cmdline() for processing commandline), leading to the
Unknown command line option warning being printed whenever options
get passed to the core hypervisor or the Dom0 kernel.
Signed-off-by: Jan Beulich jbeul...@suse.com
Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -311,6 +311,7 @@ static unsigned int __init get_argv(unsi
++argc;
else if ( prev wstrcmp(prev, L--) == 0 )
{
+--argv;
if ( options )
*options = cmdline;
break;
EFI: suppress bogus loader warning
This was accidentally lost in commit fbc3d9a220 (EFI: add
efi_arch_handle_cmdline() for processing commandline), leading to the
Unknown command line option warning being printed whenever options
get passed to the core hypervisor or the Dom0 kernel.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -311,6 +311,7 @@ static unsigned int __init get_argv(unsi
++argc;
else if ( prev wstrcmp(prev, L--) == 0 )
{
+--argv;
if ( options )
*options = cmdline;
break;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/7 v3] tools/hotplug: systemd changes for 4.5
On Fri, Dec 19, 2014 at 12:25:26PM +0100, Olaf Hering wrote: This is a resend of these two series: http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00858.html http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html New in v3 is a wrapper to run xenstored. See its patch description for details. Patch 2-6 should be applied for 4.5.0. The first and the last one still has issues with xenstored and SELinux. See below. Up to now no solution is known to me. The first patch fixes Arch Linux and does not break anything. As such it should be safe to be applied for 4.5.0. SELinux users (who build from source) should put their special mount options into fstab. Distro Could you elaborate what that is? As in what is that 'special mount options'? packages will most likely include a proper .service file. The last patch addresses the XENSTORED_TRACE issue. But SELinux will most likely still not work. Possible ways to handle launching xenstored and SELinux: - do nothing pro: - no Xen source changes required con: - possible unhappy users who build from source and still have SELinux enabled At this stage I prefer this and just have in the release notes the work-around documented. - use newly added wrapper pro: - XENSTORED_TRACE boolean is handled con: - the wrapper may have the very same issue as the current launching with sh -c 'exec xenstored'. But maybe there is a way to mark the new wrapper script as this is the native xenstored. Someone familiar with SELinux may be able to answer this. - Use ExecStart=@XENSTORED@ pro: - socket passing will most likely work con: - All options have to be passed in XENSTORED_ARGS, a new variable which is not yet mentioned in the sysconfig file. - Switching xenstored requires a private copy of xenstored.service in /etc/systemd instead of adjusting the XENSTORED= variable in the sysconfig file. - Use ExecStart=/usr/bin/env $XENSTORED pro: - $XENSTORED can be set in sysconfig file con: - may have the same socket issue as starting via shell - XENSTORED_TRACE boolean is not handled I will be offline until 2015-01-07, so any further adjustments to this series has to be done by someone else. Good luck! Olaf Olaf Hering (7): tools/hotplug: remove SELinux options from var-lib-xenstored.mount tools/hotplug: remove XENSTORED_ROOTDIR from xenstored.service tools/hotplug: xendomains.service depends on network tools/hotplug: use xencommons as EnvironmentFile in xenconsoled.service tools/hotplug: use XENCONSOLED_TRACE in xenconsoled.service tools/hotplug: remove EnvironmentFile from xen-qemu-dom0-disk-backend.service tools/hotplug: add wrapper to start xenstored .gitignore| 1 + tools/configure | 3 ++- tools/configure.ac| 1 + tools/hotplug/Linux/Makefile | 2 ++ tools/hotplug/Linux/init.d/xencommons.in | 6 -- tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in| 4 +--- tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 - tools/hotplug/Linux/systemd/xenconsoled.service.in| 6 +++--- tools/hotplug/Linux/systemd/xendomains.service.in | 2 ++ tools/hotplug/Linux/systemd/xenstored.service.in | 6 ++ tools/hotplug/Linux/xenstored.sh.in | 6 ++ 11 files changed, 24 insertions(+), 14 deletions(-) create mode 100644 tools/hotplug/Linux/xenstored.sh.in ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation Updates
On Fri, Dec 19, 2014 at 03:30:23PM +, Jan Beulich wrote: On 19.12.14 at 15:52, lars.kurth@gmail.com wrote: ** The key changes normally are changes to scalability/memory/etc. limits - maybe Jan(x86) and Ian(ARM) can look let me know of changes Iirc scalability changes on the x86 side were mostly (if not exclusively) in terms of performance improvements (in some cases getting bigger guests out of not booting at all state). Hmm, wasn't there improvements to allow more VMs per host aswell.. ? which would be worth mentioning.. xenstored related stuff iirc. -- Pasi Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation Updates
Lars, @Russell: you may want to update the XM to XL pages or create a new one and add your video I've updated the existing Wiki pages. I've also created an unpublished entry in the Video section of the XenProject.org website. Should we publish that now, or wait until release? Russ On Fri, Dec 19, 2014 at 2:55 PM, Pasi Kärkkäinen pa...@iki.fi wrote: On Fri, Dec 19, 2014 at 03:30:23PM +, Jan Beulich wrote: On 19.12.14 at 15:52, lars.kurth@gmail.com wrote: ** The key changes normally are changes to scalability/memory/etc. limits - maybe Jan(x86) and Ian(ARM) can look let me know of changes Iirc scalability changes on the x86 side were mostly (if not exclusively) in terms of performance improvements (in some cases getting bigger guests out of not booting at all state). Hmm, wasn't there improvements to allow more VMs per host aswell.. ? which would be worth mentioning.. xenstored related stuff iirc. -- Pasi Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] EFI + GRUB2 + Xen - WIP
Hi all, I was going to send EFI + GRUB2 + Xen upstream patches based on my internal work for Xen 4.3.1 last week. Sadly, I was killing various bugs surfacing on various machines in unexpected places in this almost fully featured solution. This means I was not able to do that as I planned. Additionally, I am on holiday until Christmas. So, I hope that I will be able to release first version of EFI + GRUB2 + Xen upstream patch series at the beginning of next year. However, if you wish to take a look at our internal version, which have most ideas set in stone (e.g. I am going to post GRUB2 patches almost without any changes), please drop me a line. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] kexec-tools: Read always one vmcoreinfo file
Hi Petr, On Thu, Nov 13, 2014 at 04:51:48PM +0100, Petr Tesarik wrote: Hi all, this thread got somehow forgotten because of vacations... Anyway, read below. [...] Due to delays in EFI + GRUB2 + Xen project I must postpone work on this a bit longer than I expected. I will check what is going on immediately after releasing first version of patches for above mentioned project. It looks that it will happen at the beginning of next year. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [rumpuserxen test] 32506: all pass - PUSHED
flight 32506 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32506/
Perfect :-)
All tests in this flight passed
version targeted for testing:
rumpuserxen 3f853f8ea1bc6859320a52cec7c53fef04c3dfde
baseline version:
rumpuserxen 0a0e61c12101ca4fe48da63f09971bccd331819c
People who touched revisions under test:
Antti Kantee po...@iki.fi
Martin Lucina mar...@lucina.net
jobs:
build-amd64 pass
build-i386 pass
build-amd64-pvopspass
build-i386-pvops pass
build-amd64-rumpuserxen pass
build-i386-rumpuserxen pass
test-amd64-amd64-rumpuserxen-amd64 pass
test-amd64-i386-rumpuserxen-i386 pass
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=rumpuserxen
+ revision=3f853f8ea1bc6859320a52cec7c53fef04c3dfde
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push rumpuserxen
3f853f8ea1bc6859320a52cec7c53fef04c3dfde
+ branch=rumpuserxen
+ revision=3f853f8ea1bc6859320a52cec7c53fef04c3dfde
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock
']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case $branch in
+ tree=rumpuserxen
+ xenbranch=xen-unstable
+ '[' xrumpuserxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{GitCacheProxy} or die $!;
'
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo
'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ :
'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{GitCacheProxy} or die $!;
'
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo
'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ :
'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ :
Re: [Xen-devel] Parallel make supported?
Thanks, see attached : This is on Salix 14.1 running the 3.17.4 kernel. That's not particularly relevant though, as I had exactly the same error on Debian using other kernel versions. On 19 December 2014 at 10:05, Ian Campbell ian.campb...@citrix.com wrote: On Thu, 2014-12-18 at 22:36 +, Peter Kay wrote: Is parallel make supported for xen? If I compile 4.5 rc4 (although the error exists with many other prior releases too) with make -j4 world it fails part way through with an error 2. This does not occur with a straight 'make world' It is expected to work in general, I build with -j12 all the time. There are some subdirs which enforce serialised build for various reasons, perhaps there is one more we've not spotted or perhaps there is just a bug in the Makefiles somewhere. Please post your build logs showing the error. Ian. build.log.gz Description: GNU Zip compressed data ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
xen_emul_unplug=unnecessary (kernel arg) may help you here. Also udev likes to rename your devices. Here is a lspci from a guest: [root@C63-min-tools ~]# lspci 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01) 00:03.0 VGA compatible controller: Cirrus Logic GD 5446 00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) 00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) And to help: [root@C63-min-tools ~]# ls -l /sys/class/net/*/device lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device - ../../../vif-0 lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device - ../../../vif-1 lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device - ../../../vif-2 lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device - ../../../vif-3 lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device - ../../../vif-4 lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device - ../../../vif-5 lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device - ../../../vif-6 lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device - ../../../vif-7 lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device - ../../../vif-8 lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device - ../../../vif-9 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device - ../../../:00:04.0 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device - ../../../:00:05.0 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device - ../../../:00:06.0 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device - ../../../:00:07.0 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device - ../../../:00:08.0 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device - ../../../:00:09.0 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device - ../../../:00:0a.0 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device - ../../../:00:0b.0 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device - ../../../:00:0c.0 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device - ../../../:00:0d.0 -Don Slutz On 12/19/14 07:04, Singhal, Upanshu wrote: Hello, In one of my experiment, I am building a Linux VM with Network interface model as vmxnet3. I am able to create the VM successfully, but I see that the driver loaded is vif and not vmxnet3. I am using the following option for the network interface: *vif = [ 'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr0, model=vmxnet3' ]* ** I tried with model as e1000 and it works fine. Lspci command also does not show vmxnet3. Though, qemu device help shows that vmxnet3 is supported on XEN 4.4.1 version I am using. I tried searching on internet about the right configuration for vmxnet3 with XEN, but not able to find right information. Can someone please help me on how to create a VM with vmxnet3? This experiment I am doing to compare the difference between vmxnet3 bandwidth on VMWARE ESXi vs. XEN Server. My sample VM configuration file is: # This configures an HVM rather than PV guest builder = hvm # Guest name *name = rhel-vmxnet3-xen-2.hvm* # 128-bit UUID for the domain as a hexadecimal number. # Use uuidgen to generate one if required. # The default behavior is to generate a new UUID each time the guest is started. #uuid = ---- # Enable Microsoft Hyper-V compatibile paravirtualisation / # enlightenment interfaces. Turning this on can improve Windows guest # performance and is therefore recommended #viridian = 1 # Initial memory allocation (MB) *memory = 8192* # Maximum memory (MB) # If this is greater than `memory' then the slack will start ballooned # (this assumes guest kernel support for ballooning) #maxmem = 512 # Number of VCPUS *vcpus = 8* # Network devices # A list of 'vifspec' entries as
Re: [Xen-devel] Help: VMXNET3 support with XEN 4.4.1
P.S. here is the vif line I used: vif = [ model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:a0, model=e1000,bridge=xenbr0,mac=00:0c:29:86:44:aa, model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:b4, model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:be, model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:c8, model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:d2, model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:dc, model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:e6, model=vmxnet3,bridge=xenbr0,mac=00:0c:29:86:44:f0, model=e1000,bridge=xenbr0,mac=00:0c:29:86:44:fa, ] -Don Slutz On 12/19/14 17:29, Don Slutz wrote: xen_emul_unplug=unnecessary (kernel arg) may help you here. Also udev likes to rename your devices. Here is a lspci from a guest: [root@C63-min-tools ~]# lspci 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01) 00:03.0 VGA compatible controller: Cirrus Logic GD 5446 00:04.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) 00:06.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 00:07.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 00:08.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 00:09.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 00:0a.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 00:0b.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 00:0c.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 00:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) And to help: [root@C63-min-tools ~]# ls -l /sys/class/net/*/device lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth0/device - ../../../vif-0 lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth1/device - ../../../vif-1 lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth2/device - ../../../vif-2 lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth3/device - ../../../vif-3 lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth4/device - ../../../vif-4 lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth5/device - ../../../vif-5 lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth6/device - ../../../vif-6 lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth7/device - ../../../vif-7 lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth8/device - ../../../vif-8 lrwxrwxrwx. 1 root root 0 Dec 19 17:23 /sys/class/net/eth9/device - ../../../vif-9 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic0/device - ../../../:00:04.0 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic1/device - ../../../:00:05.0 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic2/device - ../../../:00:06.0 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic3/device - ../../../:00:07.0 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic4/device - ../../../:00:08.0 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic5/device - ../../../:00:09.0 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic6/device - ../../../:00:0a.0 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic7/device - ../../../:00:0b.0 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic8/device - ../../../:00:0c.0 lrwxrwxrwx. 1 root root 0 Dec 19 17:21 /sys/class/net/pci-nic9/device - ../../../:00:0d.0 -Don Slutz On 12/19/14 07:04, Singhal, Upanshu wrote: Hello, In one of my experiment, I am building a Linux VM with Network interface model as vmxnet3. I am able to create the VM successfully, but I see that the driver loaded is vif and not vmxnet3. I am using the following option for the network interface: *vif = [ 'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr0, model=vmxnet3' ]* ** I tried with model as e1000 and it works fine. Lspci command also does not show vmxnet3. Though, qemu device help shows that vmxnet3 is supported on XEN 4.4.1 version I am using. I tried searching on internet about the right configuration for vmxnet3 with XEN, but not able to find right information. Can someone please help me on how to create a VM with vmxnet3? This experiment I am doing to compare the difference between vmxnet3 bandwidth on VMWARE ESXi vs. XEN Server. My sample VM configuration file is: # This configures an HVM rather than PV guest builder = hvm # Guest name *name = rhel-vmxnet3-xen-2.hvm* # 128-bit UUID for the domain as a hexadecimal number. # Use uuidgen to generate one if required. # The
[Xen-devel] virtio_net: Fix napi poll list corruption
David Vrabel david.vra...@citrix.com wrote:
After d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt
masking in NAPI) the napi instance is removed from the per-cpu list
prior to calling the n-poll(), and is only requeued if all of the
budget was used. This inadvertently broke netfront because netfront
does not use NAPI correctly.
A similar bug exists in virtio_net.
-- 8 --
The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
interrupt masking in NAPI) breaks virtio_net in an insidious way.
It is now required that if the entire budget is consumed when poll
returns, the napi poll_list must remain empty. However, like some
other drivers virtio_net tries to do a last-ditch check and if
there is more work it will call napi_schedule and then immediately
process some of this new work. Should the entire budget be consumed
while processing such new work then we will violate the new caller
contract.
This patch fixes this by not touching any work when we reschedule
in virtio_net.
The worst part of this bug is that the list corruption causes other
napi users to be moved off-list. In my case I was chasing a stall
in IPsec (IPsec uses netif_rx) and I only belatedly realised that it
was virtio_net which caused the stall even though the virtio_net
poll was still functioning perfectly after IPsec stalled.
Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index b8bd719..5ca9771 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -760,7 +760,6 @@ static int virtnet_poll(struct napi_struct *napi, int
budget)
container_of(napi, struct receive_queue, napi);
unsigned int r, received = 0;
-again:
received += virtnet_receive(rq, budget - received);
/* Out of packets? */
@@ -771,7 +770,6 @@ again:
napi_schedule_prep(napi)) {
virtqueue_disable_cb(rq-vq);
__napi_schedule(napi);
- goto again;
}
}
Cheers,
--
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] net: Detect drivers that reschedule NAPI and exhaust budget
On Sat, Dec 20, 2014 at 11:23:27AM +1100, Herbert Xu wrote: A similar bug exists in virtio_net. In order to detect other drivers doing this we should add something like this. -- 8 -- The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt masking in NAPI) required drivers to leave poll_list empty if the entire budget is consumed. We have already had two broken drivers so let's add a check for this. Signed-off-by: Herbert Xu herb...@gondor.apana.org.au diff --git a/net/core/dev.c b/net/core/dev.c index f411c28..88f9725 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -4620,7 +4620,11 @@ static void net_rx_action(struct softirq_action *h) */ napi_gro_flush(n, HZ = 1000); } - list_add_tail(n-poll_list, repoll); + /* Some drivers may have called napi_schedule +* prior to exhausting their budget. +*/ + if (!WARN_ON_ONCE(!list_empty(n-poll_list))) + list_add_tail(n-poll_list, repoll); } } Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-next test] 32491: regressions - FAIL
flight 32491 linux-next real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/32491/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 32431 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-rumpuserxen-amd64 8 guest-start fail like 32431 test-amd64-i386-rumpuserxen-i386 8 guest-startfail like 32431 test-amd64-i386-freebsd10-amd64 7 freebsd-install fail like 32431 test-amd64-amd64-xl-sedf 15 guest-localmigrate/x10 fail like 32431 test-armhf-armhf-xl 9 guest-start fail like 32431 test-amd64-i386-freebsd10-i386 7 freebsd-install fail like 32431 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail blocked in 32431 test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail like 32431 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-amd64-i386-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-libvirt 9 guest-start fail never pass test-armhf-armhf-libvirt 9 guest-start fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass version targeted for testing: linuxcfaa3a95dd2b402599b1d8122dc3107478db8717 baseline version: linux603ba7e41bf5d405aba22294af5d075d8898176d jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl fail test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64 fail test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64fail
Re: [Xen-devel] net: Detect drivers that reschedule NAPI and exhaust budget
On Sat, 2014-12-20 at 11:36 +1100, Herbert Xu wrote: On Sat, Dec 20, 2014 at 11:23:27AM +1100, Herbert Xu wrote: A similar bug exists in virtio_net. In order to detect other drivers doing this we should add something like this. -- 8 -- The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt masking in NAPI) required drivers to leave poll_list empty if the entire budget is consumed. We have already had two broken drivers so let's add a check for this. Signed-off-by: Herbert Xu herb...@gondor.apana.org.au diff --git a/net/core/dev.c b/net/core/dev.c index f411c28..88f9725 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -4620,7 +4620,11 @@ static void net_rx_action(struct softirq_action *h) */ napi_gro_flush(n, HZ = 1000); } - list_add_tail(n-poll_list, repoll); + /* Some drivers may have called napi_schedule + * prior to exhausting their budget. + */ + if (!WARN_ON_ONCE(!list_empty(n-poll_list))) + list_add_tail(n-poll_list, repoll); } } I do not think stack trace will point to the buggy driver ? IMO it would be better to print a single line with the netdev name ? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] net: Detect drivers that reschedule NAPI and exhaust budget
From: Eric Dumazet eric.duma...@gmail.com Date: Fri, 19 Dec 2014 17:34:48 -0800 @@ -4620,7 +4620,11 @@ static void net_rx_action(struct softirq_action *h) */ napi_gro_flush(n, HZ = 1000); } -list_add_tail(n-poll_list, repoll); +/* Some drivers may have called napi_schedule + * prior to exhausting their budget. + */ +if (!WARN_ON_ONCE(!list_empty(n-poll_list))) +list_add_tail(n-poll_list, repoll); } } I do not think stack trace will point to the buggy driver ? IMO it would be better to print a single line with the netdev name ? Right, we are already back from the poll routine and will just end up seeing the call trace leading to the software interrupt. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [seabios test] 32499: regressions - FAIL
flight 32499 seabios real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/32499/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rhel6hvm-intel 5 xen-bootfail REGR. vs. 32285 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-amd64-i386-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-libvirt 9 guest-start fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass version targeted for testing: seabios 64b76149765341168b4c073211f7b17a0f54f444 baseline version: seabios ed675ad4193bc7f929e5b39074d50672970aefa3 People who touched revisions under test: Kevin O'Connor ke...@koconnor.net jobs: build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64fail test-amd64-i386-xl-credit2 pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-amd64-xl-pvh-intelfail test-amd64-i386-rhel6hvm-intel fail test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt fail test-amd64-i386-libvirt fail test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pairpass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin
[Xen-devel] [xen-unstable test] 32503: regressions - FAIL
flight 32503 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/32503/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail REGR. vs. 32392 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-amd64-amd64-libvirt 9 guest-start fail never pass test-amd64-i386-libvirt 9 guest-start fail never pass test-armhf-armhf-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass version targeted for testing: xen 36174af3fbeb1b662c0eadbfa193e77f68cc955b baseline version: xen 2676bc915157ab474ee478d929b0928cf696b385 People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com George Dunlap george.dun...@eu.citrix.com Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Konrad Rzeszutek Wilk konrad.w...@oracle.com M A Young m.a.yo...@durham.ac.uk Michael Young m.a.yo...@durham.ac.uk Oleksandr Dmytryshyn oleksandr.dmytrys...@globallogic.com Wei Liu wei.l...@citrix.com jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64
[Xen-devel] [libvirt test] 32508: tolerable FAIL - PUSHED
flight 32508 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32508/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 9 guest-start fail never pass
test-amd64-amd64-libvirt 9 guest-start fail never pass
test-armhf-armhf-libvirt 9 guest-start fail never pass
version targeted for testing:
libvirt 1adda68a1b60a1f1a42bab5801e1529059d34ce4
baseline version:
libvirt 531aef2e1b2c5ca97bc2936c108a6fa20b60de93
People who touched revisions under test:
Ján Tomko jto...@redhat.com
jobs:
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-armhf-pvopspass
build-i386-pvops pass
test-amd64-amd64-libvirt fail
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt fail
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=libvirt
+ revision=1adda68a1b60a1f1a42bab5801e1529059d34ce4
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt
1adda68a1b60a1f1a42bab5801e1529059d34ce4
+ branch=libvirt
+ revision=1adda68a1b60a1f1a42bab5801e1529059d34ce4
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock
']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case $branch in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osst...@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{GitCacheProxy} or die $!;
'
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo
'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ :
'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
Re: [Xen-devel] net: Detect drivers that reschedule NAPI and exhaust budget
On Fri, Dec 19, 2014 at 09:40:00PM -0500, David Miller wrote: From: Eric Dumazet eric.duma...@gmail.com Date: Fri, 19 Dec 2014 17:34:48 -0800 @@ -4620,7 +4620,11 @@ static void net_rx_action(struct softirq_action *h) */ napi_gro_flush(n, HZ = 1000); } - list_add_tail(n-poll_list, repoll); + /* Some drivers may have called napi_schedule + * prior to exhausting their budget. + */ + if (!WARN_ON_ONCE(!list_empty(n-poll_list))) + list_add_tail(n-poll_list, repoll); } } I do not think stack trace will point to the buggy driver ? IMO it would be better to print a single line with the netdev name ? Right, we are already back from the poll routine and will just end up seeing the call trace leading to the software interrupt. Good point Eric. -- 8 -- The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt masking in NAPI) required drivers to leave poll_list empty if the entire budget is consumed. We have already had two broken drivers so let's add a check for this. Signed-off-by: Herbert Xu herb...@gondor.apana.org.au diff --git a/net/core/dev.c b/net/core/dev.c index f411c28..47fdc5c 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -4620,7 +4620,13 @@ static void net_rx_action(struct softirq_action *h) */ napi_gro_flush(n, HZ = 1000); } - list_add_tail(n-poll_list, repoll); + /* Some drivers may have called napi_schedule +* prior to exhausting their budget. +*/ + if (unlikely(!list_empty(n-poll_list))) + pr_warn(%s: Budget exhausted after napi rescheduled\n, n-dev ? n-dev-name : backlog); + else + list_add_tail(n-poll_list, repoll); } } Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.10 test] 32507: regressions - FAIL
flight 32507 linux-3.10 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/32507/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl 9 guest-start fail pass in 32445 test-amd64-i386-xl-multivcpu 5 xen-boot fail in 32445 pass in 32507 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 32445 pass in 32507 test-amd64-amd64-pair 4 host-install/dst_host(4) broken in 32445 pass in 32507 Regressions which are regarded as allowable (not blocking): test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 26303 test-amd64-amd64-xl-winxpsp3 7 windows-install fail like 26303 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-amd64-i386-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-amd64-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-armhf-armhf-libvirt 5 xen-boot fail never pass test-armhf-armhf-xl 5 xen-boot fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass version targeted for testing: linuxa472efc75989c7092187fe00f0400e02c495c436 baseline version: linuxbe67db109090b17b56eb8eb2190cd70700f107aa 816 people touched revisions under test, not listing them all jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl fail test-armhf-armhf-xl fail test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64
