Re: [Xen-devel] [PATCH v2 1/2] ACPI/table: Always count matched and successfully parsed entries
On 14.08.15 at 12:50, julien.gr...@citrix.com wrote: Hi Shannon, On 14/08/15 04:36, Shannon Zhao wrote: From: Tomasz Nowicki tomasz.nowi...@linaro.org Ported from Linux commit 4ceacd02f5a1795c5c697e0345ee10beef675290. acpi_parse_entries() allows to traverse all available table entries (aka subtables) by passing max_entries parameter equal to 0, but since its count variable is only incremented if max_entries is not 0, the function always returns 0 for max_entries equal to 0. It would be more useful if it returned the number of entries matched instead, so make it increment count in that case too. Acked-by: Grant Likely grant.lik...@linaro.org Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org Signed-off-by: Hanjun Guo hanjun@linaro.org Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com Signed-off-by: Shannon Zhao shannon.z...@linaro.org You may want to add an indentation to show this is the commit message from Linux and not Xen. One of the reason behind that it's Grant acked the patch for Linux and not Xen. The patch is nearly the same this time (only the lines change), but it may happen that we need to fix a bit. Which is why I find it generally better to do S-o-b: S-o-b: [Linux commit ...] S-o-b: (when no other comments need adding) which implicitly draws a line between the Linux and Xen tags. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Buggy IOMMU support in Coreboot on Chromebook Pixel 2 i7-5600U
On the VT-d troubleshooting page, I was informed to shoot you all a message if Xen had to deactivate my VT-d due to errors in my BIOS (in this case Coreboot). I am running John Lewis' Coreboot ROM for the Chromebook Pixel 2 (samus) w/ the i7-5600U processor and Xen 4.4.2 on Qubes. I downloaded and cracked open (for lack of better words) John Lewis's Coreboot image (which is a modified version of the one in the Google repos) and found that src/arch/x86/acpi.c had the same section added by the http://review.coreboot.org/#/c/1654/ commit written by Patrick Georgi a few years back that is supposed to provide ACPI DMAR tables. The problem might just be the code is out of date for modern processors or maybe it has just not been tested against many CPUs. It does appear that there has been changes to this acpi.c file in the Coreboot master branch, which makes me wonder if building against that would fix my problems. Realistically though, I have barely any experience or knowledge with Coreboot hacking and I'm assuming there is a web of dependencies that I couldn't figure out without possibly months of research, trial, and error. Anyway, just wanted to send in this report as maybe you don't get too many involving Coreboot and maybe you might find it interesting or in the minute chance you might be able to help me out. Anyway, here's the output of `xl dmesg`: Xen 4.4.2-6.fc20 (XEN) Xen version 4.4.2 (user@) (gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)) debug=n Thu Jul 23 20:12:15 UTC 2015 (XEN) Latest ChangeSet: (XEN) Bootloader: GRUB 2.00 (XEN) Command line: placeholder console=none dom0_mem=min:1024M (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) Disc information: (XEN) Found 2 MBR signatures (XEN) Found 2 EDD information structures (XEN) Xen-e820 RAM map: (XEN) - 0009fc00 (usable) (XEN) 0009fc00 - 000a (reserved) (XEN) 000f - 0010 (reserved) (XEN) 0010 - 7ce27000 (usable) (XEN) 7ce27000 - 8000 (reserved) (XEN) f000 - f400 (reserved) (XEN) fed1 - fed1a000 (reserved) (XEN) fed4 - fed45000 (reserved) (XEN) fed8 - fed85000 (reserved) (XEN) 0001 - 00047f00 (usable) (XEN) ACPI: RSDP 000F2760, 0024 (r2 CORE ) (XEN) ACPI: XSDT 7CF440E0, 004C (r1 CORE COREBOOT0 CORE 0) (XEN) ACPI: FACP 7CF48970, 00F4 (r5 CORE COREBOOT0 CORE 1) (XEN) ACPI: DSDT 7CF44250, 4720 (r2 COREv4 COREBOOT 20110725 INTL 20130117) (XEN) ACPI: FACS 7CF44210, 0040 (XEN) ACPI: HPET 7CF48A70, 0038 (r1 CORE COREBOOT0 CORE 0) (XEN) ACPI: APIC 7CF48AB0, 006C (r1 CORE COREBOOT0 CORE 0) (XEN) ACPI: MCFG 7CF48B20, 003C (r1 CORE COREBOOT0 CORE 0) (XEN) ACPI: SSDT 7CF49BC0, 0FF8 (r2 CORE COREBOOT 2A CORE 2A) (XEN) System RAM: 16317MB (16709400kB) (XEN) Domain heap initialised (XEN) Processor #0 7:13 APIC version 21 (XEN) Processor #1 7:13 APIC version 21 (XEN) Processor #3 7:13 APIC version 21 (XEN) Processor #2 7:13 APIC version 21 (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-39 (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) Not enabling x2APIC: depends on iommu_supports_eim. (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2394.544 MHz processor. (XEN) Initing memory sharing. (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) I/O virtualisation disabled (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) ENABLING IO-APIC IRQs (XEN) - Using old ACK method (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 16 KiB. (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Extended Page Tables (EPT) (XEN) - Virtual-Processor Identifiers (VPID) (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) - Unrestricted Guest (XEN) HVM: ASIDs enabled. (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB (XEN) Brought up 4 CPUs (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 - 0x204d000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 00046800-00047000 (4056562 pages to be allocated) (XEN) Init. ramdisk: 00047cb6a000-00047f00 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: 8100-8204d000 (XEN) Init. ramdisk: - (XEN) Phys-Mach map: 8204d000-83f92440 (XEN) Start info:83f93000-83f934b4 (XEN) Page tables: 83f94000-83fb9000 (XEN) Boot stack:83fb9000-83fba000 (XEN) TOTAL: 8000-8440 (XEN) ENTRY ADDRESS:
Re: [Xen-devel] [PATCH] x86/p2m: clear_identity_p2m_entry() must cope with 'relaxed' RDM mode
From: Jan Beulich [mailto:jbeul...@suse.com] Sent: Wednesday, August 12, 2015 11:06 PM Tearing down a 1:1 mapping that was never established isn't really nice (and in fact hits an ASSERT() in p2m_remove_page()). Convert from a wrapper macro to a proper function which then can take care of the situation. Also take the opportunity to remove the 'page_order' parameter of clear_identity_p2m_entry(), to make it match set_identity_p2m_entry(). Acked-by: Kevin Tian kevin.t...@intel.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xs-devel] Trying to bring up stub domain in xen-4.4-xs88306
Hi, Thanks for your reply:-) Now, I know that the windows VM is crashed due to a not fully booted stub domain. But why did the stub domain crash? Thanks:-) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] x86/HVM: hvm_map_guest_frame_rw() adjustments
From: Jan Beulich [mailto:jbeul...@suse.com] Sent: Wednesday, August 12, 2015 10:17 PM ... and its callers. While all non-nested users are made fully honor the semantics of that type, doing so in the nested case seemed insane (if doable at all, considering VMCS shadowing), and hence there the respective operations are simply made fail. One case not (yet) taken care of is that of a page getting transitioned to this type after a mapping got established. Signed-off-by: Jan Beulich jbeul...@suse.com Acked-by: Kevin Tian kevin.t...@intel.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen Security Advisory 140 - QEMU leak of uninitialized heap memory in rtl8139 device model
Hi Ian, Please find attached new patches for the 'Qemu-dm 3.4 stable branch’ (git://xenbits.xen.org/qemu-xen-3.4-testing.git) with Signed-off-by included: # sha256sum xsa140-qemut-3.4-?.patch 444b0487b6ae702b13626780b94cfe9d5b7e39c0b6ae26fc162fe93c84c83407 xsa140-qemut-3.4-1.patch b08ee945330020a522a549ce9aa118abe93624e66b925cbb5f22e0c771642afa xsa140-qemut-3.4-2.patch 21be371510876261830d3895b68d6288e57ca651fc67befb0323d3bc3bdb5b1c xsa140-qemut-3.4-3.patch 3fbd3d4a236b249bf4b2cae53d2e8242d2c5f53efd8848c879de80ae64de05c8 xsa140-qemut-3.4-4.patch 71c32327b813c8a2c9dc0e4dd3fc08bfcf1d107febaa2eae085a67781890fe2b xsa140-qemut-3.4-5.patch 5542dd9cca45586e45d5f6eb4276e61a485994ea31f2aad4ac65801832890bf1 xsa140-qemut-3.4-6.patch 908e492694dd5102280799cac6151f551aff35a08900eee33ca14fa026c8dc51 xsa140-qemut-3.4-7.patch xsa140-qemut-3.4-1.patch Description: Binary data xsa140-qemut-3.4-2.patch Description: Binary data xsa140-qemut-3.4-3.patch Description: Binary data xsa140-qemut-3.4-4.patch Description: Binary data xsa140-qemut-3.4-5.patch Description: Binary data xsa140-qemut-3.4-6.patch Description: Binary data xsa140-qemut-3.4-7.patch Description: Binary data --- Yura On Aug 13, 2015, at 18:02 PM, Ian Jackson ian.jack...@eu.citrix.com wrote: Yuriy Kohut writes (Re: Xen Security Advisory 140 - QEMU leak of uninitialized heap memory in rtl8139 device model): Please find attached patches for the 'Qemu-dm 3.4 stable branch’ (git://xenbits.xen.org/qemu-xen-3.4-testing.git): # sha256sum xsa140-qemut-3.4-?.patch a6f614aea18f5ebf37b7d462c9190d7b9426a7b2ca304f314d05b8a328c9f831 xsa140-qemut-3.4-1.patch dd3f90a407f83fdaf7efa42a5aabcc479ad88a0bc8b98d31f1809dfe81543186 xsa140-qemut-3.4-2.patch b091a84fe888362a1501faf8aa546d2b8816e0ce6e197d8da9cd0bafc0e26dbb xsa140-qemut-3.4-3.patch 454e6d0d6fe464c7a696c168ca5218fbd5d496eab1f5565bc02e391997b02a3d xsa140-qemut-3.4-4.patch def8a6a33bddd77518b9ba2f8f16b2ac4ff962c34f24a94173e41b5a82adf68a xsa140-qemut-3.4-5.patch c599838dfea5aa50eed8bc2ca373734a6ef4529738aa1d056637625d04d35875 xsa140-qemut-3.4-6.patch 6d2efbd7b492355160f38a61e0a83c5fb5be86e2a4c953cc2f4e05a2dda7001e xsa140-qemut-3.4-7.patch Hi. Thanks a lot for this. We (Xen maintainers) intend to handle these by applying this (as a bugfix) to xen.git#staging, which is the 4.6 release prep branch. They apply with some minor line offsets. We'll then feed that into our maintained stable branches in the usual way, and update the advisory. Yuriy, can I have your Signed-off-by for the backport work, in accordance with http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Signing_off_a_patch ? If so I will repost this as a formal patch series. Thanks, Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 1/2] Differentiate IO/mem resources tracked by ioreq server
Hi Paul,
On 8/13/2015 6:39 PM, Yu, Zhang wrote:
On 8/13/2015 6:16 PM, Paul Durrant wrote:
-Original Message-
From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 13 August 2015 11:06
To: xen-devel@lists.xen.org; Paul Durrant; Ian Jackson; Stefano
Stabellini; Ian
Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew Cooper
Cc: Kevin Tian; zhiyuan...@intel.com
Subject: [PATCH v4 1/2] Differentiate IO/mem resources tracked by ioreq
server
Currently in ioreq server, guest write-protected ram pages are
tracked in the same rangeset with device mmio resources. Yet
unlike device mmio, which can be in big chunks, the guest write-
protected pages may be discrete ranges with 4K bytes each.
Would the interfaces be better using xen_pfn_t rather than using
uint64_t to pass addresses round where the bottom 12 bits will always
be zero?
Paul
Thank you, Paul.
Well, I'm not quite sure if the bottom 12 bits of the address are zero.
I had thought these addresses are just guest physical ones causing
the ept violation, and not aligned down to its page address, like the
MMIO. So, if our handler code has already done that, using xen_pfn_t
could be better(my developing machine encountered some hardware
problem, will check the code tomorrow) :)
Yu
I just checked the code in hvm_select_ioreq_server(), and found value
of address is not aligned down, and the lower 12 bits are not zero.
So I wonder, is it necessary to do the shift to get a gfn, and what's
the benefit?
Thanks
Yu
This patch uses a seperate rangeset for the guest ram pages.
And a new ioreq type, IOREQ_TYPE_WP_MEM, is defined.
Note: Previously, a new hypercall or subop was suggested to map
write-protected pages into ioreq server. However, it turned out
handler of this new hypercall would be almost the same with the
existing pair - HVMOP_[un]map_io_range_to_ioreq_server, and there's
already a type parameter in this hypercall. So no new hypercall
defined, only a new type is introduced.
Signed-off-by: Yu Zhang yu.c.zh...@linux.intel.com
---
tools/libxc/include/xenctrl.h| 31 ++
tools/libxc/xc_domain.c | 55
xen/arch/x86/hvm/hvm.c | 26 ++-
xen/include/asm-x86/hvm/domain.h | 4 +--
xen/include/public/hvm/hvm_op.h | 1 +
xen/include/public/hvm/ioreq.h | 1 +
6 files changed, 115 insertions(+), 3 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h
b/tools/libxc/include/xenctrl.h
index de3c0ad..53f196d 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2010,6 +2010,37 @@ int
xc_hvm_unmap_io_range_from_ioreq_server(xc_interface *xch,
int is_mmio,
uint64_t start,
uint64_t end);
+/**
+ * This function registers a range of write-protected memory for
emulation.
+ *
+ * @parm xch a handle to an open hypervisor interface.
+ * @parm domid the domain id to be serviced
+ * @parm id the IOREQ Server id.
+ * @parm start start of range
+ * @parm end end of range (inclusive).
+ * @return 0 on success, -1 on failure.
+ */
+int xc_hvm_map_mem_range_to_ioreq_server(xc_interface *xch,
+domid_t domid,
+ioservid_t id,
+uint64_t start,
+uint64_t end);
+
+/**
+ * This function deregisters a range of write-protected memory for
emulation.
+ *
+ * @parm xch a handle to an open hypervisor interface.
+ * @parm domid the domain id to be serviced
+ * @parm id the IOREQ Server id.
+ * @parm start start of range
+ * @parm end end of range (inclusive).
+ * @return 0 on success, -1 on failure.
+ */
+int xc_hvm_unmap_mem_range_from_ioreq_server(xc_interface *xch,
+domid_t domid,
+ioservid_t id,
+uint64_t start,
+uint64_t end);
/**
* This function registers a PCI device for config space emulation.
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 2ee26fb..42aeba9 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1552,6 +1552,61 @@ int
xc_hvm_unmap_io_range_from_ioreq_server(xc_interface *xch, domid_t
domid,
return rc;
}
+int xc_hvm_map_mem_range_to_ioreq_server(xc_interface *xch,
domid_t domid,
+ioservid_t id, uint64_t
start, uint64_t end)
+{
+DECLARE_HYPERCALL;
+DECLARE_HYPERCALL_BUFFER(xen_hvm_io_range_t, arg);
+int rc;
+
+arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
+if ( arg == NULL )
+return -1;
+
+hypercall.op = __HYPERVISOR_hvm_op;
+hypercall.arg[0] = HVMOP_map_io_range_to_ioreq_server;
+
[Xen-devel] per-core power-gating
Hi, does xen support per-core power-gating (pcpg) ? -- Best Regards Hamed Rostamzadeh, MSc Student, Distributed Systems Lab, School of Computer Engineering, Iran University of Science and Technology, Tehran, Iran. https://sites.google.com/site/hamedrostamzade/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Patch x86/ldt: Make modify_ldt synchronous has been added to the 4.1-stable tree
* Greg KH gre...@linuxfoundation.org wrote: On Thu, Aug 13, 2015 at 06:38:46PM -0700, Andy Lutomirski wrote: On Thu, Aug 13, 2015 at 5:44 PM, gre...@linuxfoundation.org wrote: This is a note to let you know that I've just added the patch titled x86/ldt: Make modify_ldt synchronous This needs: https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=x86/urgentid=4809146b86c3d41ce588fdb767d021e2a80600dd and its parent. :( As that isn't in Linus's tree yet, I'll move this one back and wait a release or so before it gets merged. I just sent it to Linus, so barring a catastrophy it should be upstream soon. Thanks, Ingo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [patch added to the 3.12 stable tree] x86/xen: Probe target addresses in set_aliased_prot() before the hypercall
From: Andy Lutomirski l...@kernel.org This patch has been added to the 3.12 stable tree. If you have any objections, please let us know. === commit aa1acff356bbedfd03b544051f5b371746735d89 upstream. The update_va_mapping hypercall can fail if the VA isn't present in the guest's page tables. Under certain loads, this can result in an OOPS when the target address is in unpopulated vmap space. While we're at it, add comments to help explain what's going on. This isn't a great long-term fix. This code should probably be changed to use something like set_memory_ro. Signed-off-by: Andy Lutomirski l...@kernel.org Cc: Andrew Cooper andrew.coop...@citrix.com Cc: Andy Lutomirski l...@amacapital.net Cc: Boris Ostrovsky boris.ostrov...@oracle.com Cc: Borislav Petkov b...@alien8.de Cc: Brian Gerst brge...@gmail.com Cc: David Vrabel dvra...@cantab.net Cc: Denys Vlasenko dvlas...@redhat.com Cc: H. Peter Anvin h...@zytor.com Cc: Jan Beulich jbeul...@suse.com Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com Cc: Linus Torvalds torva...@linux-foundation.org Cc: Peter Zijlstra pet...@infradead.org Cc: Sasha Levin sasha.le...@oracle.com Cc: Steven Rostedt rost...@goodmis.org Cc: Thomas Gleixner t...@linutronix.de Cc: secur...@kernel.org secur...@kernel.org Cc: xen-devel xen-devel@lists.xen.org Link: http://lkml.kernel.org/r/0b0e55b995cda11e7829f140b833ef932fcabe3a.1438291540.git.l...@kernel.org Signed-off-by: Ingo Molnar mi...@kernel.org Signed-off-by: Jiri Slaby jsl...@suse.cz --- arch/x86/xen/enlighten.c | 40 1 file changed, 40 insertions(+) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index fa6ade76ef3f..2cbc2f2cf43e 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -480,6 +480,7 @@ static void set_aliased_prot(void *v, pgprot_t prot) pte_t pte; unsigned long pfn; struct page *page; + unsigned char dummy; ptep = lookup_address((unsigned long)v, level); BUG_ON(ptep == NULL); @@ -489,6 +490,32 @@ static void set_aliased_prot(void *v, pgprot_t prot) pte = pfn_pte(pfn, prot); + /* +* Careful: update_va_mapping() will fail if the virtual address +* we're poking isn't populated in the page tables. We don't +* need to worry about the direct map (that's always in the page +* tables), but we need to be careful about vmap space. In +* particular, the top level page table can lazily propagate +* entries between processes, so if we've switched mms since we +* vmapped the target in the first place, we might not have the +* top-level page table entry populated. +* +* We disable preemption because we want the same mm active when +* we probe the target and when we issue the hypercall. We'll +* have the same nominal mm, but if we're a kernel thread, lazy +* mm dropping could change our pgd. +* +* Out of an abundance of caution, this uses __get_user() to fault +* in the target address just in case there's some obscure case +* in which the target address isn't readable. +*/ + + preempt_disable(); + + pagefault_disable();/* Avoid warnings due to being atomic. */ + __get_user(dummy, (unsigned char __user __force *)v); + pagefault_enable(); + if (HYPERVISOR_update_va_mapping((unsigned long)v, pte, 0)) BUG(); @@ -500,6 +527,8 @@ static void set_aliased_prot(void *v, pgprot_t prot) BUG(); } else kmap_flush_unused(); + + preempt_enable(); } static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries) @@ -507,6 +536,17 @@ static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries) const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE; int i; + /* +* We need to mark the all aliases of the LDT pages RO. We +* don't need to call vm_flush_aliases(), though, since that's +* only responsible for flushing aliases out the TLBs, not the +* page tables, and Xen will flush the TLB for us if needed. +* +* To avoid confusing future readers: none of this is necessary +* to load the LDT. The hypervisor only checks this when the +* LDT is faulted in due to subsequent descriptor access. +*/ + for(i = 0; i entries; i += entries_per_page) set_aliased_prot(ldt + i, PAGE_KERNEL_RO); } -- 2.5.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 2
On 2015/8/12 17:11, Julien Grall wrote: On 12/08/2015 08:22, Shannon Zhao wrote: Hi, Hi Shannon, It's not part of the design discussion and we are avoiding to mix discussion. Can you please create another thread (or at least renaming the subject)? I'm working on re-spinning this patchset while encountering a werid problem about xzalloc_bytes. Since I need to copy some ACPI tables, I need to allocate some memory for it. So there are a few places calling xzalloc_bytes. And it fails at the fifth one. The log is shown as following: Do you copy data in the newly allocated memory between 2 xzalloc_bytes? No, I just use xzalloc_bytes to allocate some place and copy ACPI to the allocated place, modify the content, then call raw_copy_to_guest_flush_dcache to copy the modified tables to guest memory. The only thing I have in mind based on the log below is your are overriding the metadata of the memory allocator. (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ 0008fa315000 (XEN) Allocating 1:1 mappings totalling 256MB for dom0: (XEN) BANK[0] 0x009000-0x00a000 (256MB) (XEN) Grant table range: 0x0087e0-0x0087e5b000 (XEN) Loading zImage from 0008fa315000 to 9008-909e0ec8 (XEN) Hypervisor Trap. HSR=0x9644 EC=0x25 IL=1 Syndrome=0x44 (XEN) CPU0: Unexpected Trap: Hypervisor (XEN) [ Xen-4.6-unstable arm64 debug=y Not tainted ] (XEN) CPU:0 (XEN) PC: 00238b78 xmem_pool_alloc+0x348/0x4b0 (XEN) LR: 00238960 (XEN) SP: 002bf4e0 (XEN) CPSR: 2249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) Xen call trace: (XEN)[00238b78] xmem_pool_alloc+0x348/0x4b0 (PC) (XEN)[00238960] xmem_pool_alloc+0x130/0x4b0 (LR) (XEN)[00239100] _xmalloc+0xf4/0x290 (XEN)[002392b0] _xzalloc+0x14/0x38 (XEN)[00245430] construct_dom0+0xbc0/0x14cc (XEN)[0028c4c4] start_xen+0xbf4/0xcb0 (XEN)[0020060c] paging+0x84/0xbc (XEN) (XEN) (XEN) (XEN) Panic on CPU 0: (XEN) CPU0: Unexpected Trap: Hypervisor (XEN) (XEN) (XEN) (XEN) Reboot in five seconds... Regards, -- Shannon ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/HVM: honor p2m_ram_ro in hvm_map_guest_frame_rw()
On 08/14/2015 06:38 AM, Jan Beulich wrote:
On 31.07.15 at 18:06, boris.ostrov...@oracle.com wrote:
On 07/24/2015 05:41 AM, Jan Beulich wrote:
@@ -1693,14 +1703,22 @@ int nvmx_handle_vmclear(struct cpu_user_
else
{
/* Even if this VMCS isn't the current one, we must clear it. */
-vvmcs = hvm_map_guest_frame_rw(gpa PAGE_SHIFT, 0);
+bool_t writable;
+
+vvmcs = hvm_map_guest_frame_rw(gpa PAGE_SHIFT, 0, writable);
Since you replaced 'gpa PAGE_SHIFT' with 'paddr_to_pfn(gpa' above,
perhaps it should be replaced here too.
Other than that,
Reviewed-by: Boris Ostrovsky boris.ostrov...@oracle.com
I took the liberty to downgrade this to an ack (covering SVM) on
v2 (since the SVM part didn't change).
Sure. (I also reviewed v2 so you can use either tag).
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 2/2] Refactor rangeset structure for better performance.
-Original Message-
From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 14 August 2015 13:03
To: xen-devel@lists.xen.org; Paul Durrant; Ian Jackson; Stefano Stabellini;
Ian
Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew Cooper
Cc: Kevin Tian; zhiyuan...@intel.com
Subject: [PATCH v5 2/2] Refactor rangeset structure for better performance.
This patch refactors struct rangeset to base it on the red-black
tree structure, instead of on the current doubly linked list. By
now, ioreq leverages rangeset to keep track of the IO/memory
resources to be emulated. Yet when number of ranges inside one
ioreq server is very high, traversing a doubly linked list could
be time consuming. With this patch, the time complexity for
searching a rangeset can be improved from O(n) to O(log(n)).
Interfaces of rangeset still remain the same, and no new APIs
introduced.
Signed-off-by: Yu Zhang yu.c.zh...@linux.intel.com
Looks ok to me :-)
Reviewed-by: Paul Durrant paul.durr...@citrix.com
---
xen/common/rangeset.c | 82
+--
1 file changed, 60 insertions(+), 22 deletions(-)
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index 6c6293c..cde0d06 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -10,11 +10,12 @@
#include xen/sched.h
#include xen/errno.h
#include xen/rangeset.h
+#include xen/rbtree.h
#include xsm/xsm.h
/* An inclusive range [s,e] and pointer to next range in ascending order. */
struct range {
-struct list_head list;
+struct rb_node node;
unsigned long s, e;
};
@@ -24,7 +25,7 @@ struct rangeset {
struct domain *domain;
/* Ordered list of ranges contained in this set, and protecting lock. */
-struct list_head range_list;
+struct rb_root range_tree;
/* Number of ranges that can be allocated */
long nr_ranges;
@@ -45,41 +46,78 @@ struct rangeset {
static struct range *find_range(
struct rangeset *r, unsigned long s)
{
-struct range *x = NULL, *y;
+struct rb_node *node;
+struct range *x;
+struct range *prev = NULL;
-list_for_each_entry ( y, r-range_list, list )
+node = r-range_tree.rb_node;
+while ( node )
{
-if ( y-s s )
-break;
-x = y;
+x = container_of(node, struct range, node);
+if ( (s = x-s) (s = x-e) )
+return x;
+if ( s x-s )
+node = node-rb_left;
+else
+{
+prev = x;
+node = node-rb_right;
+}
}
-return x;
+return prev;
}
/* Return the lowest range in the set r, or NULL if r is empty. */
static struct range *first_range(
struct rangeset *r)
{
-if ( list_empty(r-range_list) )
-return NULL;
-return list_entry(r-range_list.next, struct range, list);
+struct rb_node *node;
+
+node = rb_first(r-range_tree);
+if ( node != NULL )
+return container_of(node, struct range, node);
+
+return NULL;
}
/* Return range following x in ascending order, or NULL if x is the highest.
*/
static struct range *next_range(
struct rangeset *r, struct range *x)
{
-if ( x-list.next == r-range_list )
-return NULL;
-return list_entry(x-list.next, struct range, list);
+struct rb_node *node;
+
+node = rb_next(x-node);
+if ( node )
+return container_of(node, struct range, node);
+
+return NULL;
}
/* Insert range y after range x in r. Insert as first range if x is NULL. */
static void insert_range(
struct rangeset *r, struct range *x, struct range *y)
{
-list_add(y-list, (x != NULL) ? x-list : r-range_list);
+struct rb_node **node;
+struct rb_node *parent = NULL;
+
+if ( x == NULL )
+node = r-range_tree.rb_node;
+else
+{
+node = x-node.rb_right;
+parent = x-node;
+}
+
+while ( *node )
+{
+parent = *node;
+node = parent-rb_left;
+}
+
+/* Add new node and rebalance the red-black tree. */
+rb_link_node(y-node, parent, node);
+rb_insert_color(y-node, r-range_tree);
}
/* Remove a range from its list and free it. */
@@ -88,7 +126,7 @@ static void destroy_range(
{
r-nr_ranges++;
-list_del(x-list);
+rb_erase(x-node, r-range_tree);
xfree(x);
}
@@ -319,7 +357,7 @@ bool_t rangeset_contains_singleton(
bool_t rangeset_is_empty(
const struct rangeset *r)
{
-return ((r == NULL) || list_empty(r-range_list));
+return ((r == NULL) || RB_EMPTY_ROOT(r-range_tree));
}
struct rangeset *rangeset_new(
@@ -332,7 +370,7 @@ struct rangeset *rangeset_new(
return NULL;
rwlock_init(r-lock);
-INIT_LIST_HEAD(r-range_list);
+r-range_tree = RB_ROOT;
r-nr_ranges = -1;
BUG_ON(flags
Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4
On Fri, 14 Aug 2015, Jan Beulich wrote: On 14.08.15 at 15:21, stefano.stabell...@eu.citrix.com wrote: On Fri, 14 Aug 2015, Jan Beulich wrote: it's even less clear how you'd expect to suppress this in other guest OSes (Windows - afaik - being able to run on ARM certainly makes it a candidate guest, even if maybe this doesn't work today), namely such not having any pcifront. And I hope this design discussion isn't limiting itself to Linux guests. We'll write down in the ABI documentation that BARs reassignments are not supported. I.e. guests doing so Will Not Work (TM), with users (usually not reading ABI docs) learning it the hard way. Not nice, but a way to handle it. The target of the ABI docs is not users, but kernel developers, who should most definitely read them and fix their kernels. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] About Xen bridged pci devices and suspend/resume for the X10SAE motherboard (SuperMicro)
On Thu, 2015-08-13 at 15:49 -0400, Konrad Rzeszutek Wilk wrote: On Mon, Aug 10, 2015 at 09:21:35PM +0300, M. Ivanov wrote: On Mon, 2015-08-10 at 10:47 -0400, Konrad Rzeszutek Wilk wrote: On Mon, Aug 10, 2015 at 05:14:28PM +0300, M. Ivanov wrote: On Mon, 2015-08-10 at 09:58 -0400, Konrad Rzeszutek Wilk wrote: On Mon, Aug 10, 2015 at 02:11:38AM +0300, M. Ivanov wrote: Hello, excuse me for bothering you, but I've read an old thread on a mailing list about X10SAE compatibility. http://lists.xen.org/archives/html/xen-devel/2014-02/msg02111.html CC-ing Xen devel. Currently I own this board and am trying to use it with Xen and be able to suspend and resume. But I am getting errors from the USB 3 Renesas controller about parity in my bios event log, and my system hangs on resume, so I was wondering if that is connected to the bridge(tundra) you've mentioned. Did you update the BIOS to the latest version? Will updating to version 3 solve my issue? Can you do a suspend/resume on your X10SAE? It did work at some point. I will find out when I am at home later today. Looking forward to your reply and am really thankful for your time, so far I've tried changing many of the settings in the bios, fiddling with Xen's kernel params, blacklisting the xhci driver, doing a xl detach. The only thing I haven't done yet is updating the bios, but Supermicro's support couldn't give me a changelog: The primary objective for ver3.0 BIOS release is to support Intel Broadwell CPUs We do not know if BIOS update will fix the issue you are seeing as we never tested it with Xen. I did test it remotely and it did something very odd. It suspended and then immediately resumed with tons of VT-d errors!? I will try again but be actually right by it. Thanks for your effort, Can you suggest a way for me to log what is happening? Since my machine just hangs up and I don't get a picture on the screen. Or when I do(sometimes) - it's just a cursor,(on a black screen with nothing else,no errors shown) and the machine doesn't react to any key combinations. On a side note: I did try updating the bios, but got some really strange result. The first time I got checksums about everything OK, (erase,flash,verify), but then it said - FDT is locked! And I am at least 90% sure I've enabled reflash in the BIOS setup prior to flashing. So I've restarted but didn't clear the CMOS(through the jumper on the board). And it said Bios v 3.0 in the setup, then I also did the Reset to optmized defaults. Tried suspending and couldn't resume like always. But perhaps currently my BIOS is in a broken/corrupted state. After that I've tried reflashing the bios again. But this time - after the messages about Erasing,Flashing,Verifying: it just froze. I didn't get any message about FDT, restarting or whatsoever. So I rebooted and it seems to work like before, says version 3.0 in the BIOS setup. I wonder if I should try clearing the CMOS and flashing again. I will be very glad if you could share any information regarding this matter. Best regards, M. Ivanov 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] PCI Pass-through in Xen ARM: Draft 4
On Fri, 14 Aug 2015, Jan Beulich wrote: On 13.08.15 at 19:01, ian.campb...@citrix.com wrote: On Thu, 2015-08-13 at 09:29 -0600, Jan Beulich wrote: A bunch of your questions seem to be about things which have been discussed at length in previous postings, it's probably worth reviewing some of those discussions. With the huge amount of mail to be read after returning from vacation I had hoped to avoid that, assuming that results of such discussion would (should) manifest themselves in the new draft i.e. I specifically avoided to join the tail of the draft 3 thread). Furthermore OSes can generally reassign BARs as they see fit (as long as the chosen addresses don't collide with anything else). Not with PV pcifront/back based setups, the BARs are fixed then I believe, even for x86/PV. That model is being followed on ARM too. I'm unaware of the mechanism to avoid such re-assignment in Linux; They simply don't work. The code to reassign BARs has never been written. it's even less clear how you'd expect to suppress this in other guest OSes (Windows - afaik - being able to run on ARM certainly makes it a candidate guest, even if maybe this doesn't work today), namely such not having any pcifront. And I hope this design discussion isn't limiting itself to Linux guests. We'll write down in the ABI documentation that BARs reassignments are not supported. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatable
On Fri, Aug 14, 2015 at 06:49:18AM -0600, Jan Beulich wrote: On 14.08.15 at 13:52, daniel.ki...@oracle.com wrote: On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote: On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote: diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h index 87b3341..27481ac 100644 --- a/xen/include/asm-x86/page.h +++ b/xen/include/asm-x86/page.h @@ -283,7 +283,7 @@ extern root_pgentry_t idle_pg_table[ROOT_PAGETABLE_ENTRIES]; extern l2_pgentry_t *compat_idle_pg_table_l2; extern unsigned int m2p_compat_vstart; extern l2_pgentry_t l2_xenmap[L2_PAGETABLE_ENTRIES], -l2_bootmap[L2_PAGETABLE_ENTRIES]; +l2_bootmap[4*L2_PAGETABLE_ENTRIES]; ? Why do we need to expand this to be 16kB? TBH, we need 8 KiB in the worst case. The worst case is when next GiB starts (e.g. 1 GiB ends and 2 GiB starts) in the middle of Xen image. In this situation we must hook up lower l2_bootmap table with lower l3_bootmap entry, higher l2_bootmap table with higher l3_bootmap entry and finally fill l2_bootmap relevant tables in proper way. Sadly, this method requires more calculations. To avoid that I have added 3 l2_bootmap tables and simply hook up one after another with relevant l3_bootmap entries. However, if you wish we can reduce number of l2_bootmap tables to two. This way code will be more complicated but we will save about 8 KiB. Wouldn't it be better (simpler) to enforce, say, 16Mb alignment in the PE32+ header (which the EFI loader would then honor)? Good idea but then we must enforce this for multiboot protocol (v1 and v2) too. multiboot2 with my patches supports that solution. However, multiboot (v1) could be a bit problematic because it means that we must set load address to 16 MiB. Are we sure that this region is available on all machines like region starting at 1 MiB? Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xsplice: Use ld-embedded build-ids
On 14.08.2015 15:54, Jan Beulich wrote:
On 14.08.15 at 14:59, mpohl...@amazon.com wrote:
On 11.08.2015 16:12, Jan Beulich wrote:
On 05.08.15 at 16:09, mpohl...@amazon.de wrote:
Todo:
* Should be moved to sysctl to only allow Dom0 access
Because of?
The discussion in this thread:
[Xen-devel] [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id
was:
--
Martin Pohlack:
We should not expose the build_id to normal guests, but only to Dom0.
A build_id uniquely identifies a specific build and I don't see how that
information would be required from DomU. It might actually help an
attacker to build his return-oriented programming exploit against a
specific build.
The normal version numbers should be enough to know about capabilities
and API.
Andrew Cooper:
It will need its own XSM hook, but need not be strictly limited to just
dom0.
--
So I'm confused - I asked why Dom0 only and then you point me to
Andrew saying it doesn't need to be Dom0 only?
Sorry about that, my (not expressed) thinking was that we should
restrict that to Dom0 for the XSM-disabled case.
@@ -360,11 +366,30 @@ DO(xen_version)(int cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
case XENVER_build_id:
{
-xen_build_id_t build_id;
+xen_build_id_t ascii_id;
+Elf_Note * n = (Elf_Note *)__note_gnu_build_id_start;
+char * binary_id;
+int i;
+
+memset(ascii_id, 0, sizeof(ascii_id));
+
+/* check if we really have a build-id */
+if ( NT_GNU_BUILD_ID != n-type )
+return 0;
This needs to signal an error.
Yes, ENOSYS, (or ENOENT, ENODATA)?
Definitely not ENOSYS. ENODATA or EOPNOTSUPP.
Jan
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4
On 14.08.15 at 15:21, stefano.stabell...@eu.citrix.com wrote: On Fri, 14 Aug 2015, Jan Beulich wrote: it's even less clear how you'd expect to suppress this in other guest OSes (Windows - afaik - being able to run on ARM certainly makes it a candidate guest, even if maybe this doesn't work today), namely such not having any pcifront. And I hope this design discussion isn't limiting itself to Linux guests. We'll write down in the ABI documentation that BARs reassignments are not supported. I.e. guests doing so Will Not Work (TM), with users (usually not reading ABI docs) learning it the hard way. Not nice, but a way to handle it. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 23/23] x86: add multiboot2 protocol support for relocatable images
On Fri, Aug 14, 2015 at 01:57:01PM +0200, Daniel Kiper wrote: On Tue, Aug 11, 2015 at 12:56:58PM -0400, Konrad Rzeszutek Wilk wrote: On Mon, Jul 20, 2015 at 04:29:18PM +0200, Daniel Kiper wrote: Add multiboot2 protocol support for relocatable images. Only GRUB2 with relevant patches understands that feature. Older multiboot You may want to enumerate what those 'relevant' patches are. protocol (regardless of version) compatible loaders ignore it and everything works as usual. Signed-off-by: Daniel Kiper daniel.ki...@oracle.com --- xen/arch/x86/boot/head.S | 46 + xen/arch/x86/x86_64/asm-offsets.c |1 + xen/include/xen/multiboot2.h | 13 +++ 3 files changed, 50 insertions(+), 10 deletions(-) diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S index d484f68..2520e48 100644 --- a/xen/arch/x86/boot/head.S +++ b/xen/arch/x86/boot/head.S @@ -81,6 +81,13 @@ multiboot1_header_end: /* Align modules at page boundry. */ mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED) +/* Load address preference. */ +mb2ht_init MB2_HT(RELOCATABLE), MB2_HT(OPTIONAL), \ + sym_phys(start), /* Min load address. */ \ We could go straight to __start? This specifies lowest load address not entry point. Ah right. And the __start can be moved somewhere inside the .text code, while 'start' is always at offset 0. Thank you! Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xsplice: Use ld-embedded build-ids
On 14.08.15 at 14:59, mpohl...@amazon.com wrote:
On 11.08.2015 16:12, Jan Beulich wrote:
On 05.08.15 at 16:09, mpohl...@amazon.de wrote:
Todo:
* Should be moved to sysctl to only allow Dom0 access
Because of?
The discussion in this thread:
[Xen-devel] [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id
was:
--
Martin Pohlack:
We should not expose the build_id to normal guests, but only to Dom0.
A build_id uniquely identifies a specific build and I don't see how that
information would be required from DomU. It might actually help an
attacker to build his return-oriented programming exploit against a
specific build.
The normal version numbers should be enough to know about capabilities
and API.
Andrew Cooper:
It will need its own XSM hook, but need not be strictly limited to just
dom0.
--
So I'm confused - I asked why Dom0 only and then you point me to
Andrew saying it doesn't need to be Dom0 only?
@@ -360,11 +366,30 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void)
arg)
case XENVER_build_id:
{
-xen_build_id_t build_id;
+xen_build_id_t ascii_id;
+Elf_Note * n = (Elf_Note *)__note_gnu_build_id_start;
+char * binary_id;
+int i;
+
+memset(ascii_id, 0, sizeof(ascii_id));
+
+/* check if we really have a build-id */
+if ( NT_GNU_BUILD_ID != n-type )
+return 0;
This needs to signal an error.
Yes, ENOSYS, (or ENOENT, ENODATA)?
Definitely not ENOSYS. ENODATA or EOPNOTSUPP.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v2 0/5] Multi-queue support for xen-blkfront and xen-blkback
On 08/13/2015 12:46 AM, Rafal Mielniczuk wrote: On 12/08/15 11:17, Bob Liu wrote: On 08/12/2015 01:32 AM, Jens Axboe wrote: On 08/11/2015 03:45 AM, Rafal Mielniczuk wrote: On 11/08/15 07:08, Bob Liu wrote: On 08/10/2015 11:52 PM, Jens Axboe wrote: On 08/10/2015 05:03 AM, Rafal Mielniczuk wrote: ... Hello, We rerun the tests for sequential reads with the identical settings but with Bob Liu's multiqueue patches reverted from dom0 and guest kernels. The results we obtained were *better* than the results we got with multiqueue patches applied: fio_threads io_depth block_size 1-queue_iops 8-queue_iops *no-mq-patches_iops* 8 32 512 158K 264K 321K 8 321K 157K 260K 328K 8 322K 157K 258K 336K 8 324K 148K 257K 308K 8 328K 124K 207K 188K 8 32 16K84K 105K 82K 8 32 32K50K 54K 36K 8 32 64K24K 27K 16K 8 32 128K11K 13K 11K We noticed that the requests are not merged by the guest when the multiqueue patches are applied, which results in a regression for small block sizes (RealSSD P320h's optimal block size is around 32-64KB). We observed similar regression for the Dell MZ-5EA1000-0D3 100 GB 2.5 Internal SSD As I understand blk-mq layer bypasses I/O scheduler which also effectively disables merges. Could you explain why it is difficult to enable merging in the blk-mq layer? That could help closing the performance gap we observed. Otherwise, the tests shows that the multiqueue patches does not improve the performance, at least when it comes to sequential read/writes operations. blk-mq still provides merging, there should be no difference there. Does the xen patches set BLK_MQ_F_SHOULD_MERGE? Yes. Is it possible that xen-blkfront driver dequeue requests too fast after we have multiple hardware queues? Because new requests don't have the chance merging with old requests which were already dequeued and issued. For some reason we don't see merges even when we set multiqueue to 1. Below are some stats from the guest system when doing sequential 4KB reads: $ fio --name=test --ioengine=libaio --direct=1 --rw=read --numjobs=8 --iodepth=32 --time_based=1 --runtime=300 --bs=4KB --filename=/dev/xvdb $ iostat -xt 5 /dev/xvdb avg-cpu: %user %nice %system %iowait %steal %idle 0.500.002.73 85.142.009.63 Device: rrqm/s wrqm/s r/s w/s rkB/swkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util xvdb 0.00 0.00 156926.000.00 627704.00 0.00 8.0030.060.190.190.00 0.01 100.48 $ cat /sys/block/xvdb/queue/scheduler none $ cat /sys/block/xvdb/queue/nomerges 0 Relevant bits from the xenstore configuration on the dom0: /local/domain/0/backend/vbd/2/51728/dev = xvdb /local/domain/0/backend/vbd/2/51728/backend-kind = vbd /local/domain/0/backend/vbd/2/51728/type = phy /local/domain/0/backend/vbd/2/51728/multi-queue-max-queues = 1 /local/domain/2/device/vbd/51728/multi-queue-num-queues = 1 /local/domain/2/device/vbd/51728/ring-ref = 9 /local/domain/2/device/vbd/51728/event-channel = 60 If you add --iodepth-batch=16 to that fio command line? Both mq and non-mq relies on plugging to get batching in the use case above, otherwise IO is dispatched immediately. O_DIRECT is immediate. I'd be more interested in seeing a test case with buffered IO of a file system on top of the xvdb device, if we're missing merging for that case, then that's a much bigger issue. I was using the null block driver for xen blk-mq test. There were not merges happen any more even after patch: https://lkml.org/lkml/2015/7/13/185 (Which just converted xen block driver to use blk-mq apis) Will try a file system soon. I have more results for the guest with and without the patch https://lkml.org/lkml/2015/7/13/185 applied to the latest stable kernel (4.1.5). Thank you. Command line used was: fio --name=test --ioengine=libaio --rw=read --numjobs=8 \ --iodepth=32 --time_based=1 --runtime=300 --bs=4KB \ --filename=/dev/xvdb --direct=(0 and 1) --iodepth_batch=16 without patch (--direct=1): xvdb: ios=18696304/0, merge=75763177/0, ticks=11323872/0, in_queue=11344352, util=100.00% with patch (--direct=1): xvdb: ios=43709976/0, merge=97/0, ticks=8851972/0, in_queue=8902928, util=100.00% So request merge can happen just more difficult to be triggered. How about the iops of both cases? without patch buffered (--direct=0): xvdb: ios=1079051/0, merge=76/0,
[Xen-devel] [xen-4.4-testing test] 60673: regressions - FAIL
flight 60673 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/60673/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail REGR. vs. 60152 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt-qcow2 9 debian-di-installfail REGR. vs. 60217 test-amd64-i386-libvirt 11 guest-start fail like 60217 test-amd64-amd64-libvirt 11 guest-start fail like 60217 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 60217 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a build-amd64-rumpuserxen 6 xen-buildfail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-xl-qcow2 9 debian-di-installfail never pass test-armhf-armhf-xl-raw 9 debian-di-installfail never pass test-amd64-amd64-xl-qcow2 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass build-i386-rumpuserxen6 xen-buildfail never pass test-armhf-armhf-libvirt-vhd 9 debian-di-installfail never pass test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass test-armhf-armhf-libvirt 11 guest-start fail never pass test-amd64-i386-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 21 leak-check/checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass version targeted for testing: xen 3646b134c1673f09c0a239de10b0da4c9265c8e8 baseline version: xen 214fd40a20fa5988b4ea021c2d06e8aca8dda184 Last test of basis60217 2015-08-01 07:47:04 Z 13 days Testing same since60673 2015-08-12 12:38:56 Z1 days1 attempts People who touched revisions under test: Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Jim Fehlig jfeh...@suse.com Konrad Rzeszutek Wilk konrad.w...@oracle.com Wei Liu wei.l...@citrix.com jobs: build-amd64-xend pass build-i386-xend pass 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 fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-armhf-armhf-xl
Re: [Xen-devel] [PATCH v4 1/2] Differentiate IO/mem resources tracked by ioreq server
-Original Message- From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] Sent: 14 August 2015 08:41 To: Paul Durrant; xen-devel@lists.xen.org; Ian Jackson; Stefano Stabellini; Ian Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew Cooper Cc: Kevin Tian; zhiyuan...@intel.com Subject: Re: [Xen-devel] [PATCH v4 1/2] Differentiate IO/mem resources tracked by ioreq server Hi Paul, On 8/13/2015 6:39 PM, Yu, Zhang wrote: On 8/13/2015 6:16 PM, Paul Durrant wrote: -Original Message- From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com] Sent: 13 August 2015 11:06 To: xen-devel@lists.xen.org; Paul Durrant; Ian Jackson; Stefano Stabellini; Ian Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew Cooper Cc: Kevin Tian; zhiyuan...@intel.com Subject: [PATCH v4 1/2] Differentiate IO/mem resources tracked by ioreq server Currently in ioreq server, guest write-protected ram pages are tracked in the same rangeset with device mmio resources. Yet unlike device mmio, which can be in big chunks, the guest write- protected pages may be discrete ranges with 4K bytes each. Would the interfaces be better using xen_pfn_t rather than using uint64_t to pass addresses round where the bottom 12 bits will always be zero? Paul Thank you, Paul. Well, I'm not quite sure if the bottom 12 bits of the address are zero. I had thought these addresses are just guest physical ones causing the ept violation, and not aligned down to its page address, like the MMIO. So, if our handler code has already done that, using xen_pfn_t could be better(my developing machine encountered some hardware problem, will check the code tomorrow) :) Yu I just checked the code in hvm_select_ioreq_server(), and found value of address is not aligned down, and the lower 12 bits are not zero. So I wonder, is it necessary to do the shift to get a gfn, and what's the benefit? Well, you can only make whole pages mmio_dm_write and I was assuming an emulator that did so would be interested in writes anywhere in the page. Maybe that assumption is wrong? Paul Thanks Yu This patch uses a seperate rangeset for the guest ram pages. And a new ioreq type, IOREQ_TYPE_WP_MEM, is defined. Note: Previously, a new hypercall or subop was suggested to map write-protected pages into ioreq server. However, it turned out handler of this new hypercall would be almost the same with the existing pair - HVMOP_[un]map_io_range_to_ioreq_server, and there's already a type parameter in this hypercall. So no new hypercall defined, only a new type is introduced. Signed-off-by: Yu Zhang yu.c.zh...@linux.intel.com --- tools/libxc/include/xenctrl.h| 31 ++ tools/libxc/xc_domain.c | 55 xen/arch/x86/hvm/hvm.c | 26 ++- xen/include/asm-x86/hvm/domain.h | 4 +-- xen/include/public/hvm/hvm_op.h | 1 + xen/include/public/hvm/ioreq.h | 1 + 6 files changed, 115 insertions(+), 3 deletions(-) diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h index de3c0ad..53f196d 100644 --- a/tools/libxc/include/xenctrl.h +++ b/tools/libxc/include/xenctrl.h @@ -2010,6 +2010,37 @@ int xc_hvm_unmap_io_range_from_ioreq_server(xc_interface *xch, int is_mmio, uint64_t start, uint64_t end); +/** + * This function registers a range of write-protected memory for emulation. + * + * @parm xch a handle to an open hypervisor interface. + * @parm domid the domain id to be serviced + * @parm id the IOREQ Server id. + * @parm start start of range + * @parm end end of range (inclusive). + * @return 0 on success, -1 on failure. + */ +int xc_hvm_map_mem_range_to_ioreq_server(xc_interface *xch, +domid_t domid, +ioservid_t id, +uint64_t start, +uint64_t end); + +/** + * This function deregisters a range of write-protected memory for emulation. + * + * @parm xch a handle to an open hypervisor interface. + * @parm domid the domain id to be serviced + * @parm id the IOREQ Server id. + * @parm start start of range + * @parm end end of range (inclusive). + * @return 0 on success, -1 on failure. + */ +int xc_hvm_unmap_mem_range_from_ioreq_server(xc_interface *xch, +domid_t domid, +ioservid_t id, +uint64_t start, +uint64_t end); /** * This function registers a PCI device for config
Re: [Xen-devel] Redhat 6 VM crash on Xen when cpu number reaches 64
Hi all: Now a days, we tested Redhat 6.2(6.4) on Xen(version 4.1.2). If we config the cpu number more than 32, it'll show 32 in the VM, and if we config it 64 cpus, the VM will crash and the log is list below. Can someone tell us why is this happening? Old RHEL6 kernels don't have support for VCPU info placement for PVHVM (VCPUOP_register_vcpu_info call) so only 32 VCPUs are supported. This is fixed in current 6.6.z kernel. Hi Vitaly, Is there any official announcement of this on Redhat website? We did not find any explanation about this, can you help us to find it? thanks very much thanks ===crash log= CPU: CPU feature rdtscp disabled on xen guest CPU: CPU feature constant_tsc disabled on xen guest mce: CPU supports 0 MCE banks #32 CPU32: Stuck ?? #33 CPU33: Stuck ?? ... -- Vitaly ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Trying to bring up stub domain in xen-4.4-xs88306
Hi, I compared the hvm domain start log when using device model stub domain with that when using dom0 qemu: the former log: [2015-08-12 17:11:24] (d1) [ 135.565586] PCI-ISA link 0 routed to IRQ5 [2015-08-12 17:11:24] (d1) [ 135.565648] PCI-ISA link 1 routed to IRQ10 [2015-08-12 17:11:24] (d1) [ 135.565710] PCI-ISA link 2 routed to IRQ11 [2015-08-12 17:11:24] (d1) [ 135.565770] PCI-ISA link 3 routed to IRQ5 [2015-08-12 17:11:24] (d1) [ 135.566884] *** HVMLoader assertion '(devfn != PCI_ISA_DEVFN) || ((vendor_id == 0x8086) [2015-08-12 17:11:24] (d1) [ 135.566968] (device_id == 0x7000))' failed at pci.c:112 [2015-08-12 17:11:24] (d1) [ 135.567012] *** HVMLoader crashed. the latter: [2015-08-14 14:11:40] (XEN) [ 274.839099] irq.c:270: Dom1 PCI link 0 changed 0 - 5 [2015-08-14 14:11:40] (d1) [ 274.839170] PCI-ISA link 0 routed to IRQ5 [2015-08-14 14:11:40] (XEN) [ 274.839741] irq.c:270: Dom1 PCI link 1 changed 0 - 10 [2015-08-14 14:11:40] (d1) [ 274.839841] PCI-ISA link 1 routed to IRQ10 [2015-08-14 14:11:40] (XEN) [ 274.839974] irq.c:270: Dom1 PCI link 2 changed 0 - 11 [2015-08-14 14:11:40] (d1) [ 274.840050] PCI-ISA link 2 routed to IRQ11 [2015-08-14 14:11:40] (XEN) [ 274.840144] irq.c:270: Dom1 PCI link 3 changed 0 - 5 [2015-08-14 14:11:40] (d1) [ 274.840213] PCI-ISA link 3 routed to IRQ5 [2015-08-14 14:11:40] (d1) [ 274.851269] pci dev 01:2 INTD-IRQ5 [2015-08-14 14:11:40] (d1) [ 274.854295] pci dev 01:3 INTA-IRQ10 [2015-08-14 14:11:40] (d1) [ 274.857918] pci dev 02:0 INTA-IRQ11 [2015-08-14 14:11:40] (d1) [ 274.861777] pci dev 03:0 INTC-IRQ10 [2015-08-14 14:11:40] (d1) [ 274.865560] pci dev 04:0 INTA-IRQ5 [2015-08-14 14:11:40] (d1) [ 274.917245] No RAM in high memory; setting high_mem resource base to 1 It seems that when using dom0 qemu, the PCI configuration instructions are intercepted by xen hypervisor, while when using qemu stub domain, these instructions are not intercepted. Why? Thanks:-) On 13 August 2015 at 15:04, Xuehan Xu xxhdx1985...@gmail.com wrote: Hi, everyone. I'm trying to run a Windows HVM vm with stub domain in xenserver-6.5, whose internal xen version is xen-4.4-xs88306. After I started the vm, both the vm and its corresponding stub domain crashed. Here is the related content in hypervisor.log. The domain ID of the windows vm is 1, and the stub domain's id is 2. [2015-08-12 17:11:24] (d1) [ 135.564650] HVM Loader [2015-08-12 17:11:24] (d1) [ 135.564756] Detected Xen v4.4.1-xs88306 [2015-08-12 17:11:24] (d1) [ 135.564850] Xenbus rings @0xfeffc000, event channel 2 [2015-08-12 17:11:24] (d1) [ 135.565048] System requested ROMBIOS [2015-08-12 17:11:24] (d1) [ 135.565090] CPU speed is 2494 MHz [2015-08-12 17:11:24] (d2) [ 135.565234] Bootstrapping... [2015-08-12 17:11:24] (d2) [ 135.565275] Xen Minimal OS! [2015-08-12 17:11:24] (d2) [ 135.565284] start_info: 0x585000(VA) [2015-08-12 17:11:24] (d2) [ 135.565289] nr_pages: 0x2000 [2015-08-12 17:11:24] (d2) [ 135.565293] shared_inf: 0xbda9e000(MA) [2015-08-12 17:11:24] (d2) [ 135.565296] pt_base: 0x588000(VA) [2015-08-12 17:11:24] (d2) [ 135.565300] nr_pt_frames: 0x7 [2015-08-12 17:11:24] (d2) [ 135.565304] mfn_list: 0x575000(VA) [2015-08-12 17:11:24] (d2) [ 135.565307]mod_start: 0x0(VA) [2015-08-12 17:11:24] (d2) [ 135.565311] mod_len: 0 [2015-08-12 17:11:24] (d2) [ 135.565314]flags: 0x0 [2015-08-12 17:11:24] (d2) [ 135.565318] cmd_line: [2015-08-12 17:11:24] (d2) [ 135.565374] stack: 0x534660-0x554660 [2015-08-12 17:11:24] (d2) [ 135.565381] MM: Init [2015-08-12 17:11:24] (d2) [ 135.565385] _text: 0x0(VA) [2015-08-12 17:11:24] (d2) [ 135.565389] _etext: 0x1203b2(VA) [2015-08-12 17:11:24] (d2) [ 135.565393]_erodata: 0x176000(VA) [2015-08-12 17:11:24] (d2) [ 135.565396] _edata: 0x17bf88(VA) [2015-08-12 17:11:24] (d2) [ 135.565399] stack start: 0x534660(VA) [2015-08-12 17:11:24] (d2) [ 135.565402]_end: 0x574f68(VA) [2015-08-12 17:11:24] (d2) [ 135.565406] start_pfn: 592 [2015-08-12 17:11:24] (d2) [ 135.565410] max_pfn: 2000 [2015-08-12 17:11:24] (d2) [ 135.565414] Mapping memory range 0x80 - 0x200 [2015-08-12 17:11:24] (d1) [ 135.565525] Relocating guest memory for lowmem MMIO space enabled [2015-08-12 17:11:24] (d1) [ 135.565586] PCI-ISA link 0 routed to IRQ5 [2015-08-12 17:11:24] (d1) [ 135.565648] PCI-ISA link 1 routed to IRQ10 [2015-08-12 17:11:24] (d1) [ 135.565710] PCI-ISA link 2 routed to IRQ11 [2015-08-12 17:11:24] (d1) [ 135.565770] PCI-ISA link 3 routed to IRQ5 [2015-08-12 17:11:24] (d1) [ 135.566884] *** HVMLoader assertion '(devfn != PCI_ISA_DEVFN) || ((vendor_id == 0x8086) [2015-08-12 17:11:24] (d1) [ 135.566968] (device_id == 0x7000))' failed at pci.c:112 [2015-08-12 17:11:24] (d1) [ 135.567012] *** HVMLoader crashed. [2015-08-12 17:11:24] (d2) [ 135.568790] setting 0x0-0x176000 readonly [2015-08-12 17:11:24] (d2) [
Re: [Xen-devel] Buggy IOMMU support in Coreboot on Chromebook Pixel 2 i7-5600U
On 14/08/15 08:13, fowlsl...@riseup.net wrote: On the VT-d troubleshooting page, I was informed to shoot you all a message if Xen had to deactivate my VT-d due to errors in my BIOS (in this case Coreboot). I am running John Lewis' Coreboot ROM for the Chromebook Pixel 2 (samus) w/ the i7-5600U processor and Xen 4.4.2 on Qubes. I downloaded and cracked open (for lack of better words) John Lewis's Coreboot image (which is a modified version of the one in the Google repos) and found that src/arch/x86/acpi.c had the same section added by the http://review.coreboot.org/#/c/1654/ commit written by Patrick Georgi a few years back that is supposed to provide ACPI DMAR tables. The problem might just be the code is out of date for modern processors or maybe it has just not been tested against many CPUs. It does appear that there has been changes to this acpi.c file in the Coreboot master branch, which makes me wonder if building against that would fix my problems. Realistically though, I have barely any experience or knowledge with Coreboot hacking and I'm assuming there is a web of dependencies that I couldn't figure out without possibly months of research, trial, and error. Anyway, just wanted to send in this report as maybe you don't get too many involving Coreboot and maybe you might find it interesting or in the minute chance you might be able to help me out. Anyway, here's the output of `xl dmesg`: Please reboot and use iommu=verbose,debug on the Xen command line, which will offer more information. ~Andrew Xen 4.4.2-6.fc20 (XEN) Xen version 4.4.2 (user@) (gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)) debug=n Thu Jul 23 20:12:15 UTC 2015 (XEN) Latest ChangeSet: (XEN) Bootloader: GRUB 2.00 (XEN) Command line: placeholder console=none dom0_mem=min:1024M (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) Disc information: (XEN) Found 2 MBR signatures (XEN) Found 2 EDD information structures (XEN) Xen-e820 RAM map: (XEN) - 0009fc00 (usable) (XEN) 0009fc00 - 000a (reserved) (XEN) 000f - 0010 (reserved) (XEN) 0010 - 7ce27000 (usable) (XEN) 7ce27000 - 8000 (reserved) (XEN) f000 - f400 (reserved) (XEN) fed1 - fed1a000 (reserved) (XEN) fed4 - fed45000 (reserved) (XEN) fed8 - fed85000 (reserved) (XEN) 0001 - 00047f00 (usable) (XEN) ACPI: RSDP 000F2760, 0024 (r2 CORE ) (XEN) ACPI: XSDT 7CF440E0, 004C (r1 CORE COREBOOT0 CORE0) (XEN) ACPI: FACP 7CF48970, 00F4 (r5 CORE COREBOOT0 CORE1) (XEN) ACPI: DSDT 7CF44250, 4720 (r2 COREv4 COREBOOT 20110725 INTL 20130117) (XEN) ACPI: FACS 7CF44210, 0040 (XEN) ACPI: HPET 7CF48A70, 0038 (r1 CORE COREBOOT0 CORE0) (XEN) ACPI: APIC 7CF48AB0, 006C (r1 CORE COREBOOT0 CORE0) (XEN) ACPI: MCFG 7CF48B20, 003C (r1 CORE COREBOOT0 CORE0) (XEN) ACPI: SSDT 7CF49BC0, 0FF8 (r2 CORE COREBOOT 2A CORE 2A) (XEN) System RAM: 16317MB (16709400kB) (XEN) Domain heap initialised (XEN) Processor #0 7:13 APIC version 21 (XEN) Processor #1 7:13 APIC version 21 (XEN) Processor #3 7:13 APIC version 21 (XEN) Processor #2 7:13 APIC version 21 (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-39 (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) Not enabling x2APIC: depends on iommu_supports_eim. (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2394.544 MHz processor. (XEN) Initing memory sharing. (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) I/O virtualisation disabled (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) ENABLING IO-APIC IRQs (XEN) - Using old ACK method (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 16 KiB. (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Extended Page Tables (EPT) (XEN) - Virtual-Processor Identifiers (VPID) (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) - Unrestricted Guest (XEN) HVM: ASIDs enabled. (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB (XEN) Brought up 4 CPUs (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 - 0x204d000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 00046800-00047000 (4056562 pages to be allocated) (XEN) Init. ramdisk: 00047cb6a000-00047f00 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: 8100-8204d000 (XEN) Init. ramdisk: - (XEN) Phys-Mach map: 8204d000-83f92440 (XEN) Start info:83f93000-83f934b4 (XEN) Page tables:
Re: [Xen-devel] [xs-devel] Trying to bring up stub domain in xen-4.4-xs88306
PCI configuration space is not emulated by the hypervisor. There must be an external emulator to handle config cycles which, in the general case, is either QEMU or a stub domain. Either one of these must be running *before* the guest is unpaused and hence allowed to generate I/O emulation requests. If your stubdom configuration is not working then you need to figure out: a) Whether the stubdom is actually starting up at all. b) Whether it is shutting down prematurely. E.g. I found that having a ‘serial=’ line in my xl.cfg was enough to cause a stubdom to die. c) Whether the stubdom is actually hooking into Xen correctly, for which you’ll need to add some printks into Xen… look at functions with ‘ioreq_server’ in the name in xen/arch/x86/hvm/hvm.c Paul From: xs-devel-requ...@lists.xenserver.org [mailto:xs-devel-requ...@lists.xenserver.org] On Behalf Of Xuehan Xu Sent: 14 August 2015 09:05 To: xs-de...@lists.xenserver.org; xen-devel@lists.xen.org Subject: Re: [xs-devel] Trying to bring up stub domain in xen-4.4-xs88306 Hi, I compared the hvm domain start log when using device model stub domain with that when using dom0 qemu: the former log: [2015-08-12 17:11:24] (d1) [ 135.565586] PCI-ISA link 0 routed to IRQ5 [2015-08-12 17:11:24] (d1) [ 135.565648] PCI-ISA link 1 routed to IRQ10 [2015-08-12 17:11:24] (d1) [ 135.565710] PCI-ISA link 2 routed to IRQ11 [2015-08-12 17:11:24] (d1) [ 135.565770] PCI-ISA link 3 routed to IRQ5 [2015-08-12 17:11:24] (d1) [ 135.566884] *** HVMLoader assertion '(devfn != PCI_ISA_DEVFN) || ((vendor_id == 0x8086) [2015-08-12 17:11:24] (d1) [ 135.566968] (device_id == 0x7000))' failed at pci.c:112 [2015-08-12 17:11:24] (d1) [ 135.567012] *** HVMLoader crashed. the latter: [2015-08-14 14:11:40] (XEN) [ 274.839099] irq.c:270: Dom1 PCI link 0 changed 0 - 5 [2015-08-14 14:11:40] (d1) [ 274.839170] PCI-ISA link 0 routed to IRQ5 [2015-08-14 14:11:40] (XEN) [ 274.839741] irq.c:270: Dom1 PCI link 1 changed 0 - 10 [2015-08-14 14:11:40] (d1) [ 274.839841] PCI-ISA link 1 routed to IRQ10 [2015-08-14 14:11:40] (XEN) [ 274.839974] irq.c:270: Dom1 PCI link 2 changed 0 - 11 [2015-08-14 14:11:40] (d1) [ 274.840050] PCI-ISA link 2 routed to IRQ11 [2015-08-14 14:11:40] (XEN) [ 274.840144] irq.c:270: Dom1 PCI link 3 changed 0 - 5 [2015-08-14 14:11:40] (d1) [ 274.840213] PCI-ISA link 3 routed to IRQ5 [2015-08-14 14:11:40] (d1) [ 274.851269] pci dev 01:2 INTD-IRQ5 [2015-08-14 14:11:40] (d1) [ 274.854295] pci dev 01:3 INTA-IRQ10 [2015-08-14 14:11:40] (d1) [ 274.857918] pci dev 02:0 INTA-IRQ11 [2015-08-14 14:11:40] (d1) [ 274.861777] pci dev 03:0 INTC-IRQ10 [2015-08-14 14:11:40] (d1) [ 274.865560] pci dev 04:0 INTA-IRQ5 [2015-08-14 14:11:40] (d1) [ 274.917245] No RAM in high memory; setting high_mem resource base to 1 It seems that when using dom0 qemu, the PCI configuration instructions are intercepted by xen hypervisor, while when using qemu stub domain, these instructions are not intercepted. Why? Thanks:-) On 13 August 2015 at 15:04, Xuehan Xu xxhdx1985...@gmail.commailto:xxhdx1985...@gmail.com wrote: Hi, everyone. I'm trying to run a Windows HVM vm with stub domain in xenserver-6.5, whose internal xen version is xen-4.4-xs88306. After I started the vm, both the vm and its corresponding stub domain crashed. Here is the related content in hypervisor.log. The domain ID of the windows vm is 1, and the stub domain's id is 2. [2015-08-12 17:11:24] (d1) [ 135.564650] HVM Loader [2015-08-12 17:11:24] (d1) [ 135.564756] Detected Xen v4.4.1-xs88306 [2015-08-12 17:11:24] (d1) [ 135.564850] Xenbus rings @0xfeffc000, event channel 2 [2015-08-12 17:11:24] (d1) [ 135.565048] System requested ROMBIOS [2015-08-12 17:11:24] (d1) [ 135.565090] CPU speed is 2494 MHz [2015-08-12 17:11:24] (d2) [ 135.565234] Bootstrapping... [2015-08-12 17:11:24] (d2) [ 135.565275] Xen Minimal OS! [2015-08-12 17:11:24] (d2) [ 135.565284] start_info: 0x585000(VA) [2015-08-12 17:11:24] (d2) [ 135.565289] nr_pages: 0x2000 [2015-08-12 17:11:24] (d2) [ 135.565293] shared_inf: 0xbda9e000(MA) [2015-08-12 17:11:24] (d2) [ 135.565296] pt_base: 0x588000(VA) [2015-08-12 17:11:24] (d2) [ 135.565300] nr_pt_frames: 0x7 [2015-08-12 17:11:24] (d2) [ 135.565304] mfn_list: 0x575000(VA) [2015-08-12 17:11:24] (d2) [ 135.565307]mod_start: 0x0(VA) [2015-08-12 17:11:24] (d2) [ 135.565311] mod_len: 0 [2015-08-12 17:11:24] (d2) [ 135.565314]flags: 0x0 [2015-08-12 17:11:24] (d2) [ 135.565318] cmd_line: [2015-08-12 17:11:24] (d2) [ 135.565374] stack: 0x534660-0x554660 [2015-08-12 17:11:24] (d2) [ 135.565381] MM: Init [2015-08-12 17:11:24] (d2) [ 135.565385] _text: 0x0(VA) [2015-08-12 17:11:24] (d2) [ 135.565389] _etext: 0x1203b2(VA) [2015-08-12 17:11:24] (d2) [ 135.565393]_erodata: 0x176000(VA) [2015-08-12 17:11:24] (d2) [ 135.565396] _edata: 0x17bf88(VA) [2015-08-12 17:11:24] (d2) [ 135.565399]
[Xen-devel] xen/arm: Crash when allocating memory for ACPI table (Was Re: Design doc of adding ACPI support for arm64 on Xen - version 2)
(Renaming the subject) Hi Shannon, On 14/08/15 15:05, Shannon Zhao wrote: On 2015/8/12 17:11, Julien Grall wrote: On 12/08/2015 08:22, Shannon Zhao wrote: Hi, Hi Shannon, It's not part of the design discussion and we are avoiding to mix discussion. Can you please create another thread (or at least renaming the subject)? I'm working on re-spinning this patchset while encountering a werid problem about xzalloc_bytes. Since I need to copy some ACPI tables, I need to allocate some memory for it. So there are a few places calling xzalloc_bytes. And it fails at the fifth one. The log is shown as following: Do you copy data in the newly allocated memory between 2 xzalloc_bytes? No, I just use xzalloc_bytes to allocate some place and copy ACPI to the allocated place, modify the content, then call raw_copy_to_guest_flush_dcache to copy the modified tables to guest memory. Can you provide the code and show which call is crashing? Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatable
On 14.08.15 at 15:59, daniel.ki...@oracle.com wrote: On Fri, Aug 14, 2015 at 06:49:18AM -0600, Jan Beulich wrote: On 14.08.15 at 13:52, daniel.ki...@oracle.com wrote: On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote: On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote: diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h index 87b3341..27481ac 100644 --- a/xen/include/asm-x86/page.h +++ b/xen/include/asm-x86/page.h @@ -283,7 +283,7 @@ extern root_pgentry_t idle_pg_table[ROOT_PAGETABLE_ENTRIES]; extern l2_pgentry_t *compat_idle_pg_table_l2; extern unsigned int m2p_compat_vstart; extern l2_pgentry_t l2_xenmap[L2_PAGETABLE_ENTRIES], -l2_bootmap[L2_PAGETABLE_ENTRIES]; +l2_bootmap[4*L2_PAGETABLE_ENTRIES]; ? Why do we need to expand this to be 16kB? TBH, we need 8 KiB in the worst case. The worst case is when next GiB starts (e.g. 1 GiB ends and 2 GiB starts) in the middle of Xen image. In this situation we must hook up lower l2_bootmap table with lower l3_bootmap entry, higher l2_bootmap table with higher l3_bootmap entry and finally fill l2_bootmap relevant tables in proper way. Sadly, this method requires more calculations. To avoid that I have added 3 l2_bootmap tables and simply hook up one after another with relevant l3_bootmap entries. However, if you wish we can reduce number of l2_bootmap tables to two. This way code will be more complicated but we will save about 8 KiB. Wouldn't it be better (simpler) to enforce, say, 16Mb alignment in the PE32+ header (which the EFI loader would then honor)? Good idea but then we must enforce this for multiboot protocol (v1 and v2) too. multiboot2 with my patches supports that solution. However, multiboot (v1) could be a bit problematic because it means that we must set load address to 16 MiB. Are we sure that this region is available on all machines like region starting at 1 MiB? This region being which one? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4
On 14.08.15 at 16:03, stefano.stabell...@eu.citrix.com wrote: On Fri, 14 Aug 2015, Jan Beulich wrote: On 14.08.15 at 15:21, stefano.stabell...@eu.citrix.com wrote: On Fri, 14 Aug 2015, Jan Beulich wrote: it's even less clear how you'd expect to suppress this in other guest OSes (Windows - afaik - being able to run on ARM certainly makes it a candidate guest, even if maybe this doesn't work today), namely such not having any pcifront. And I hope this design discussion isn't limiting itself to Linux guests. We'll write down in the ABI documentation that BARs reassignments are not supported. I.e. guests doing so Will Not Work (TM), with users (usually not reading ABI docs) learning it the hard way. Not nice, but a way to handle it. The target of the ABI docs is not users, but kernel developers, who should most definitely read them and fix their kernels. ??? (We're talking of unmodified, closed source OSes here.) Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen/arm: Crash when allocating memory for ACPI table (Was Re: Design doc of adding ACPI support for arm64 on Xen - version 2)
Hi Julien, On 2015/8/14 22:17, Julien Grall wrote: (Renaming the subject) Hi Shannon, On 14/08/15 15:05, Shannon Zhao wrote: On 2015/8/12 17:11, Julien Grall wrote: On 12/08/2015 08:22, Shannon Zhao wrote: Hi, Hi Shannon, It's not part of the design discussion and we are avoiding to mix discussion. Can you please create another thread (or at least renaming the subject)? I'm working on re-spinning this patchset while encountering a werid problem about xzalloc_bytes. Since I need to copy some ACPI tables, I need to allocate some memory for it. So there are a few places calling xzalloc_bytes. And it fails at the fifth one. The log is shown as following: Do you copy data in the newly allocated memory between 2 xzalloc_bytes? No, I just use xzalloc_bytes to allocate some place and copy ACPI to the allocated place, modify the content, then call raw_copy_to_guest_flush_dcache to copy the modified tables to guest memory. Can you provide the code and show which call is crashing? Oh, sorry. The code is not on hand as it stays at my working computer. From previous debug, it fails at the xzalloc_bytes. Because I add two printk before and after the xzalloc_bytes, only the before one shows. The code calling route is like below: acpi_create_fadt(); acpi_create_gtdt(); acpi_create_madt(); acpi_create_stao(); acpi_create_xsdt(); acpi_map_rsdp(); acpi_map_rest_table(); acpi_create_est(); acpi_create_mmap(); ... Within everyone of these functions, it will call xzalloc_bytes to allocate memory and call raw_copy_to_guest_flush_dcache to copy the modified tables to guest memory. And this failure happened at acpi_create_xsdt(). If I add xzalloc_bytes(1000) before acpi_create_xsdt() like below: acpi_create_fadt(); acpi_create_gtdt(); acpi_create_madt(); acpi_create_stao(); xzalloc_bytes(1000); acpi_create_xsdt(); acpi_map_rsdp(); acpi_map_rest_table(); acpi_create_est(); acpi_create_mmap(); ... The failure will not happen at acpi_create_xsdt() but at acpi_create_mmap(). -- Shannon ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 0/2] Port two ACPI fixes from Linux
On 2015/8/14 22:29, Jan Beulich wrote: On 14.08.15 at 16:16, shannon.z...@linaro.org wrote: On 2015/8/14 18:24, Jan Beulich wrote: On 14.08.15 at 05:36, zhaoshengl...@huawei.com wrote: From: Shannon Zhao shannon.z...@linaro.org Len Brown (1): ACPI: disable ACPI cleanly when bad RSDP found Tomasz Nowicki (1): ACPI/table: Always count matched and successfully parsed entries These look good now, but is there a reason you didn't also port the third commit I had referred you to (95df812dbd)? Oh, sorry, forgot that. So this two patches could go first and port 95df812dbd later or send a new version with 95df812dbd? Since the patches will have to wait for the tree to re-open, there's no big difference to me (I'd hope to have the 3rd patch from you by the time they all could get committed). Ok, will send a new version. Thanks, -- Shannon ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatable
On Fri, Aug 14, 2015 at 08:32:05AM -0600, Jan Beulich wrote: On 14.08.15 at 15:59, daniel.ki...@oracle.com wrote: On Fri, Aug 14, 2015 at 06:49:18AM -0600, Jan Beulich wrote: On 14.08.15 at 13:52, daniel.ki...@oracle.com wrote: On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote: On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote: diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h index 87b3341..27481ac 100644 --- a/xen/include/asm-x86/page.h +++ b/xen/include/asm-x86/page.h @@ -283,7 +283,7 @@ extern root_pgentry_t idle_pg_table[ROOT_PAGETABLE_ENTRIES]; extern l2_pgentry_t *compat_idle_pg_table_l2; extern unsigned int m2p_compat_vstart; extern l2_pgentry_t l2_xenmap[L2_PAGETABLE_ENTRIES], -l2_bootmap[L2_PAGETABLE_ENTRIES]; +l2_bootmap[4*L2_PAGETABLE_ENTRIES]; ? Why do we need to expand this to be 16kB? TBH, we need 8 KiB in the worst case. The worst case is when next GiB starts (e.g. 1 GiB ends and 2 GiB starts) in the middle of Xen image. In this situation we must hook up lower l2_bootmap table with lower l3_bootmap entry, higher l2_bootmap table with higher l3_bootmap entry and finally fill l2_bootmap relevant tables in proper way. Sadly, this method requires more calculations. To avoid that I have added 3 l2_bootmap tables and simply hook up one after another with relevant l3_bootmap entries. However, if you wish we can reduce number of l2_bootmap tables to two. This way code will be more complicated but we will save about 8 KiB. Wouldn't it be better (simpler) to enforce, say, 16Mb alignment in the PE32+ header (which the EFI loader would then honor)? Good idea but then we must enforce this for multiboot protocol (v1 and v2) too. multiboot2 with my patches supports that solution. However, multiboot (v1) could be a bit problematic because it means that we must set load address to 16 MiB. Are we sure that this region is available on all machines like region starting at 1 MiB? This region being which one? 16 MiB - 32 MiB. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4
On Fri, 14 Aug 2015, Jan Beulich wrote: On 14.08.15 at 16:03, stefano.stabell...@eu.citrix.com wrote: On Fri, 14 Aug 2015, Jan Beulich wrote: On 14.08.15 at 15:21, stefano.stabell...@eu.citrix.com wrote: On Fri, 14 Aug 2015, Jan Beulich wrote: it's even less clear how you'd expect to suppress this in other guest OSes (Windows - afaik - being able to run on ARM certainly makes it a candidate guest, even if maybe this doesn't work today), namely such not having any pcifront. And I hope this design discussion isn't limiting itself to Linux guests. We'll write down in the ABI documentation that BARs reassignments are not supported. I.e. guests doing so Will Not Work (TM), with users (usually not reading ABI docs) learning it the hard way. Not nice, but a way to handle it. The target of the ABI docs is not users, but kernel developers, who should most definitely read them and fix their kernels. ??? (We're talking of unmodified, closed source OSes here.) If you are thinking of Windows for ARM64, there isn't one yet. When/if it will become available, there are going to be a number of issues to address before we can run it as a guest on Xen on ARM with the current architecture which doesn't do emulation. I am hopeful that we'll be able to have a discussion on ABI issues such as this one. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen/arm: Crash when allocating memory for ACPI table (Was Re: Design doc of adding ACPI support for arm64 on Xen - version 2)
On 14/08/15 15:35, Shannon Zhao wrote: Do you copy data in the newly allocated memory between 2 xzalloc_bytes? No, I just use xzalloc_bytes to allocate some place and copy ACPI to the allocated place, modify the content, then call raw_copy_to_guest_flush_dcache to copy the modified tables to guest memory. Can you provide the code and show which call is crashing? Oh, sorry. The code is not on hand as it stays at my working computer. From previous debug, it fails at the xzalloc_bytes. Because I add two printk before and after the xzalloc_bytes, only the before one shows. The code calling route is like below: acpi_create_fadt(); acpi_create_gtdt(); acpi_create_madt(); acpi_create_stao(); acpi_create_xsdt(); acpi_map_rsdp(); acpi_map_rest_table(); acpi_create_est(); acpi_create_mmap(); ... Within everyone of these functions, it will call xzalloc_bytes to allocate memory and call raw_copy_to_guest_flush_dcache to copy the modified tables to guest memory. And this failure happened at acpi_create_xsdt(). When I asked if you copy data between 2 calls of xzalloc_bytes you said no ... But here you say the invert ... So do you copy data between two call or not? (FIY, raw_copy_to_guest_flush_dcache is copying data). If I add xzalloc_bytes(1000) before acpi_create_xsdt() like below: acpi_create_fadt(); acpi_create_gtdt(); acpi_create_madt(); acpi_create_stao(); xzalloc_bytes(1000); acpi_create_xsdt(); acpi_map_rsdp(); acpi_map_rest_table(); acpi_create_est(); acpi_create_mmap(); ... The failure will not happen at acpi_create_xsdt() but at acpi_create_mmap(). Ok, so it's likely a memory corruption. You need to check the bound you ara using when copying the data to the guest or from the ACPI in general. Or maybe you just didn't allocate enough space. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4
On 14/08/15 15:37, Stefano Stabellini wrote: On Fri, 14 Aug 2015, Jan Beulich wrote: On 14.08.15 at 16:03, stefano.stabell...@eu.citrix.com wrote: On Fri, 14 Aug 2015, Jan Beulich wrote: On 14.08.15 at 15:21, stefano.stabell...@eu.citrix.com wrote: On Fri, 14 Aug 2015, Jan Beulich wrote: it's even less clear how you'd expect to suppress this in other guest OSes (Windows - afaik - being able to run on ARM certainly makes it a candidate guest, even if maybe this doesn't work today), namely such not having any pcifront. And I hope this design discussion isn't limiting itself to Linux guests. We'll write down in the ABI documentation that BARs reassignments are not supported. I.e. guests doing so Will Not Work (TM), with users (usually not reading ABI docs) learning it the hard way. Not nice, but a way to handle it. The target of the ABI docs is not users, but kernel developers, who should most definitely read them and fix their kernels. ??? (We're talking of unmodified, closed source OSes here.) If you are thinking of Windows for ARM64, there isn't one yet. When/if it will become available, there are going to be a number of issues to address before we can run it as a guest on Xen on ARM with the current architecture which doesn't do emulation. I am hopeful that we'll be able to have a discussion on ABI issues such as this one. It may be worth to read [1] where the Xen ARM architecture is explained. Regards, [1] http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions_whitepaper -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 0/2] Port two ACPI fixes from Linux
Hi Jan, On 2015/8/14 18:24, Jan Beulich wrote: On 14.08.15 at 05:36, zhaoshengl...@huawei.com wrote: From: Shannon Zhao shannon.z...@linaro.org Len Brown (1): ACPI: disable ACPI cleanly when bad RSDP found Tomasz Nowicki (1): ACPI/table: Always count matched and successfully parsed entries These look good now, but is there a reason you didn't also port the third commit I had referred you to (95df812dbd)? Oh, sorry, forgot that. So this two patches could go first and port 95df812dbd later or send a new version with 95df812dbd? Thanks, -- Shannon ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 0/2] Port two ACPI fixes from Linux
On 14.08.15 at 16:16, shannon.z...@linaro.org wrote: On 2015/8/14 18:24, Jan Beulich wrote: On 14.08.15 at 05:36, zhaoshengl...@huawei.com wrote: From: Shannon Zhao shannon.z...@linaro.org Len Brown (1): ACPI: disable ACPI cleanly when bad RSDP found Tomasz Nowicki (1): ACPI/table: Always count matched and successfully parsed entries These look good now, but is there a reason you didn't also port the third commit I had referred you to (95df812dbd)? Oh, sorry, forgot that. So this two patches could go first and port 95df812dbd later or send a new version with 95df812dbd? Since the patches will have to wait for the tree to re-open, there's no big difference to me (I'd hope to have the 3rd patch from you by the time they all could get committed). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen/arm: Crash when allocating memory for ACPI table (Was Re: Design doc of adding ACPI support for arm64 on Xen - version 2)
On 14/08/15 15:49, Shannon Zhao wrote: Ok, so it's likely a memory corruption. You need to check the bound you ara using when copying the data to the guest or from the ACPI in general. Or maybe you just didn't allocate enough space. But it fails at the xzalloc_bytes itself. not at copy function. Because the previous copy may have overwritten the metadata of the memory allocator... If those metadata are corrupted, xalloc_bytes we act weirdly such as crashing Xen. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen/arm: Crash when allocating memory for ACPI table (Was Re: Design doc of adding ACPI support for arm64 on Xen - version 2)
On 2015/8/14 22:53, Julien Grall wrote: On 14/08/15 15:49, Shannon Zhao wrote: Ok, so it's likely a memory corruption. You need to check the bound you ara using when copying the data to the guest or from the ACPI in general. Or maybe you just didn't allocate enough space. But it fails at the xzalloc_bytes itself. not at copy function. Because the previous copy may have overwritten the metadata of the memory allocator... If those metadata are corrupted, xalloc_bytes we act weirdly such as crashing Xen. Ok, will check it. Thanks. -- Shannon ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen/arm: Crash when allocating memory for ACPI table (Was Re: Design doc of adding ACPI support for arm64 on Xen - version 2)
On 2015/8/14 22:41, Julien Grall wrote: On 14/08/15 15:35, Shannon Zhao wrote: Do you copy data in the newly allocated memory between 2 xzalloc_bytes? No, I just use xzalloc_bytes to allocate some place and copy ACPI to the allocated place, modify the content, then call raw_copy_to_guest_flush_dcache to copy the modified tables to guest memory. Can you provide the code and show which call is crashing? Oh, sorry. The code is not on hand as it stays at my working computer. From previous debug, it fails at the xzalloc_bytes. Because I add two printk before and after the xzalloc_bytes, only the before one shows. The code calling route is like below: acpi_create_fadt(); acpi_create_gtdt(); acpi_create_madt(); acpi_create_stao(); acpi_create_xsdt(); acpi_map_rsdp(); acpi_map_rest_table(); acpi_create_est(); acpi_create_mmap(); ... Within everyone of these functions, it will call xzalloc_bytes to allocate memory and call raw_copy_to_guest_flush_dcache to copy the modified tables to guest memory. And this failure happened at acpi_create_xsdt(). When I asked if you copy data between 2 calls of xzalloc_bytes you said no ... But here you say the invert ... So do you copy data between two call or not? (FIY, raw_copy_to_guest_flush_dcache is copying data). Oh, I thought you mean that if I copy data between the two places allocated by xzalloc_bytes. If I add xzalloc_bytes(1000) before acpi_create_xsdt() like below: acpi_create_fadt(); acpi_create_gtdt(); acpi_create_madt(); acpi_create_stao(); xzalloc_bytes(1000); acpi_create_xsdt(); acpi_map_rsdp(); acpi_map_rest_table(); acpi_create_est(); acpi_create_mmap(); ... The failure will not happen at acpi_create_xsdt() but at acpi_create_mmap(). Ok, so it's likely a memory corruption. You need to check the bound you ara using when copying the data to the guest or from the ACPI in general. Or maybe you just didn't allocate enough space. But it fails at the xzalloc_bytes itself. not at copy function. -- Shannon ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.3-testing test] 60674: regressions - FAIL
flight 60674 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/60674/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-amd64 19 guest-start/debianhvm.repeat fail REGR. vs. 58884 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 58884 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt 11 guest-start fail like 58884 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass build-amd64-rumpuserxen 6 xen-buildfail never pass build-i386-rumpuserxen6 xen-buildfail never pass test-armhf-armhf-libvirt-qcow2 6 xen-boot fail never pass test-armhf-armhf-xl 6 xen-boot fail never pass test-armhf-armhf-xl-raw 6 xen-boot fail never pass test-armhf-armhf-libvirt-vhd 6 xen-boot fail never pass test-armhf-armhf-xl-vhd 6 xen-boot fail never pass test-armhf-armhf-xl-arndale 6 xen-boot fail never pass test-armhf-armhf-xl-multivcpu 6 xen-boot fail never pass test-armhf-armhf-xl-qcow2 6 xen-boot fail never pass test-armhf-armhf-libvirt 6 xen-boot fail never pass test-armhf-armhf-xl-cubietruck 6 xen-boot fail never pass test-armhf-armhf-xl-credit2 6 xen-boot fail never pass test-armhf-armhf-libvirt-raw 6 xen-boot fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 21 leak-check/checkfail never pass version targeted for testing: xen 3bcb2c062a02e3c45d3f87478d2cbe1a134d395c baseline version: xen e7c022977eb83822edb52919a3748ebfa5705b5d Last test of basis58884 2015-06-24 18:47:05 Z 50 days Failing since 60151 2015-07-30 18:41:03 Z 14 days3 attempts Testing same since60674 2015-08-12 13:40:25 Z2 days1 attempts People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com David Scott dave.sc...@citrix.com Ian Campbell ian,campb...@citrix.com Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Jim Fehlig jfeh...@suse.com Kevin Wolf kw...@redhat.com Konrad Rzeszutek Wilk konrad.w...@oracle.com Matthew Daley mat...@gmail.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-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-armhf-armhf-xl fail test-amd64-i386-xl pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64fail
[Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 3
This document is going to explain the design details of Xen booting with
ACPI on ARM. Maybe parts of it may not be appropriate. Any comments are
welcome.
Changes v2-v3:
* remove the two HVM_PARAMs for grant table and let linux kernel use
xlated_setup_gnttab_pages() to setup grant table.
* don't modify GTDT table
* add definition of event-channel interrupt flag
* state that route all Xen unused interrupt to Dom0
* state that reusing existing PCI bus_notifier for PCI devices MMIO mapping
To Xen itself booting with ACPI, this is similar to Linux kernel except
that Xen doesn't parse DSDT table. So I'll skip this part and focus on
how Xen prepares ACPI tables for Dom0 and how Xen passes them to Dom0.
1. Copy and change some EFI and ACPI tables
---
a) Copy EFI_SYSTEM_TABLE and change the value of FirmwareVendor,
VendorGuid, VendorTable, ConfigurationTable. These changes are not very
special and it just assign values to these members.
b) Create EFI_MEMORY_DESCRIPTOR table. This will add memory start and
size information of Dom0. And Dom0 will get the memory information
through this EFI table.
c) Copy FADT table. Change the value of arm_boot_flags to enable PSCI
and HVC. Let the hypervisor_id be XenVMM in order to tell Dom0 that it
runs on Xen hypervisor, then Dom0 could through HVM_PARAM to get some
informations for booting necessity, such as event-channel interrupt.
Change header revison, length and checksum as well.
d) Copy MADT table. According to the value of dom0_max_vcpus to change
the number GICC entries.
e) Create STAO table. This table is a new added one that's used to
define a list of ACPI namespace names that are to be ignored by the OSPM
in Dom0. Currently we use it to tell OSPM should ignore UART defined in
SPCR table.
f) Copy XSDT table. Add a new table entry for STAO and change other
table's entries.
g) Change the value of xsdt_physical_address in RSDP table.
h) The rest of tables are not copied or changed. They are reused
including DSDT, SPCR, GTDT, etc.
All these tables will be copied to Dom0 memory except that the reused
tables(DSDT, SPCR, GTDT, etc) will be mapped to Dom0.
2. Create minimal DT to pass required information to Dom0
--
The minimal DT mainly passes Dom0 bootargs, address and size of initrd
(if available), address and size of uefi system table, address and size
of uefi memory table, uefi-mmap-desc-size and uefi-mmap-desc-ver.
An example of the minimal DT:
/ {
#address-cells = 2;
#size-cells = 1;
chosen {
bootargs = kernel=Image console=hvc0 earlycon=pl011,0x1c09
root=/dev/vda2 rw rootfstype=ext4 init=/bin/sh acpi=force;
linux,initrd-start = 0x;
linux,initrd-end = 0x;
linux,uefi-system-table = 0x;
linux,uefi-mmap-start = 0x;
linux,uefi-mmap-size = 0x;
linux,uefi-mmap-desc-size = 0x;
linux,uefi-mmap-desc-ver = 0x;
};
};
For details loook at
https://github.com/torvalds/linux/blob/master/Documentation/arm/uefi.txt
3. Dom0 gets grant table and event channel irq information
---
Make Linux call xlated_setup_gnttab_pages() to setup grant table. So it
doesn't need Xen pass grant table start and size information to Dom0.
To event channel interrupt, reuse HVM_PARAM_CALLBACK_IRQ and add a new
delivery type to get it.
val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI (ARM and ARM64
only)
The definition of flag reusing the definition of xenv table. Bit 0
stands interrupt mode and bit 1 stands interrupt polarity.
As said above, we assign the hypervisor_id be XenVMM to tell Dom0 that
it runs on Xen hypervisor. Then Dom0 could get it through hypercall
HVMOP_get_param.
4. Map MMIO regions
---
Register a bus_notifier for platform and amba bus in Linux. Add a new
XENMAPSPACE XENMAPSPACE_dev_mmio. Within the register, check if the
device is newly added, then call hypercall XENMEM_add_to_physmap to map
the mmio regions.
For PCI bus device, it could reuse the existing PCI bus_notifier like
X86.
5. Route device interrupts to Dom0
--
Route all the SPI interrupts to Dom0 before Dom0 booting, except the
interrupts used by Xen. For uart, it could get the interrupt from SPCR
table and exclude it. For SMMU, it could get the interrupts from IORT
table and exclude them as well.
Thanks,
--
Shannon
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4
On 14.08.15 at 16:45, julien.gr...@citrix.com wrote: On 14/08/15 15:37, Stefano Stabellini wrote: If you are thinking of Windows for ARM64, there isn't one yet. When/if it will become available, there are going to be a number of issues to address before we can run it as a guest on Xen on ARM with the current architecture which doesn't do emulation. I am hopeful that we'll be able to have a discussion on ABI issues such as this one. It may be worth to read [1] where the Xen ARM architecture is explained. Regards, [1] http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions_whitepaper Neither Stefano's nor your reply really make a lot of sense to me: I realize you currently require a cooperating guest, but when designing something like pass-through it would seem natural to me to try to allow for other guest kinds in the future. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 3
On 14/08/15 15:59, Shannon Zhao wrote:
2. Create minimal DT to pass required information to Dom0
--
The minimal DT mainly passes Dom0 bootargs, address and size of initrd
(if available), address and size of uefi system table, address and size
of uefi memory table, uefi-mmap-desc-size and uefi-mmap-desc-ver.
An example of the minimal DT:
/ {
#address-cells = 2;
#size-cells = 1;
chosen {
bootargs = kernel=Image console=hvc0 earlycon=pl011,0x1c09
root=/dev/vda2 rw rootfstype=ext4 init=/bin/sh acpi=force;
linux,initrd-start = 0x;
linux,initrd-end = 0x;
linux,uefi-system-table = 0x;
linux,uefi-mmap-start = 0x;
linux,uefi-mmap-size = 0x;
linux,uefi-mmap-desc-size = 0x;
linux,uefi-mmap-desc-ver = 0x;
};
};
For details loook at
https://github.com/torvalds/linux/blob/master/Documentation/arm/uefi.txt
I would have expect a summary on the discussion we had on the previous
thread [1].
Note that linux,initrd-* are well defined given that Xen, U-boot and
other bootloaders are using them. And IIRC, it's Linux specific.
Although, linux,uefi-* are not well defined (only used internally by
Linux betwen the EFI stub and the kernel) and we expect other OS to use
them in the future.
So I would prefer to the linux, dropped for them.
3. Dom0 gets grant table and event channel irq information
---
Make Linux call xlated_setup_gnttab_pages() to setup grant table. So it
doesn't need Xen pass grant table start and size information to Dom0.
The design doc should be in general OS agnostic. I would say here:
The OS will have to find a place himself in the memory map for the grant
table region.
For instance, Linux can make usage of xlated_setup_gnttab_pages.
To event channel interrupt, reuse HVM_PARAM_CALLBACK_IRQ and add a new
delivery type to get it.
val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI (ARM and ARM64
only)
The definition of flag reusing the definition of xenv table. Bit 0
stands interrupt mode and bit 1 stands interrupt polarity.
Either give a link to the XENV table or explain what means the value in
each bit (i.e what 0 and 1 stands for?).
I would prefer the later.
As said above, we assign the hypervisor_id be XenVMM to tell Dom0 that
it runs on Xen hypervisor. Then Dom0 could get it through hypercall
HVMOP_get_param.
Regards,
[1] http://lists.xen.org/archives/html/xen-devel/2015-08/msg01074.html
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Empty memory nodes in VNUMA
On Fri, Aug 14, 2015 at 11:19:53AM -0400, Boris Ostrovsky wrote: What is the purpose of 'nr_vmemranges nr_vnodes' test in xc_domain_setvnuma()? Can't we have nodes with no memory? If that's the case, this check will still miss configurations when a node spans multiple memory ranges. For example, this fails: vcpus = 4 vnuma = [ [ pnode=0,size=2048,vcpus=0-1 ], [ pnode=1,size=1800 ], [ pnode=2,size=0,vcpus=2-3 ], [ pnode=3,size=100 ] ] but this vcpus = 4 vnuma = [ [ pnode=0,size=2048,vcpus=0-1 ], [ pnode=1,size=1801 ], [ pnode=2,size=0,vcpus=2-3 ], [ pnode=3,size=100 ] ] does not: because of MMIO hole this will cause a second 1MB range to be created on node 1 (in libxl__vnuma_build_vmemrange_hvm()). Can we drop this check? I would say yes. There is certainly such hardware that some NUMA node has 0 memory. Note that this function was written in the early day of vNUMA (4.5). I think that function has the assumption that each vnode has one vmemrange. Try removing that check and see what happens? But, how far are you willing to go? Do you want system with no vmemranges at all (that means, no memory at all)? If so that nr_vmemranges == 0 check should also be removed. Just kidding... Wei. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Empty memory nodes in VNUMA
On 08/14/2015 11:35 AM, Wei Liu wrote: On Fri, Aug 14, 2015 at 11:19:53AM -0400, Boris Ostrovsky wrote: What is the purpose of 'nr_vmemranges nr_vnodes' test in xc_domain_setvnuma()? Can't we have nodes with no memory? If that's the case, this check will still miss configurations when a node spans multiple memory ranges. For example, this fails: vcpus = 4 vnuma = [ [ pnode=0,size=2048,vcpus=0-1 ], [ pnode=1,size=1800 ], [ pnode=2,size=0,vcpus=2-3 ], [ pnode=3,size=100 ] ] but this vcpus = 4 vnuma = [ [ pnode=0,size=2048,vcpus=0-1 ], [ pnode=1,size=1801 ], [ pnode=2,size=0,vcpus=2-3 ], [ pnode=3,size=100 ] ] does not: because of MMIO hole this will cause a second 1MB range to be created on node 1 (in libxl__vnuma_build_vmemrange_hvm()). Can we drop this check? I would say yes. There is certainly such hardware that some NUMA node has 0 memory. Note that this function was written in the early day of vNUMA (4.5). I think that function has the assumption that each vnode has one vmemrange. Try removing that check and see what happens? I already did --- you think I'd ask without first trying? ;-) Yes, it works fine --- one a couple of tests that I tried. Do you want me to send a patch? -boris But, how far are you willing to go? Do you want system with no vmemranges at all (that means, no memory at all)? If so that nr_vmemranges == 0 check should also be removed. Just kidding... Wei. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4
On Thu, 13 Aug 2015, Jan Beulich wrote:
On 13.08.15 at 11:42, mja...@caviumnetworks.com wrote:
2.1pci_hostbridge and pci_hostbridge_ops
-
The init function in the PCI host driver calls to register hostbridge
callbacks:
int pci_hostbridge_register(pci_hostbridge_t *pcihb);
struct pci_hostbridge_ops {
u32 (*pci_conf_read)(struct pci_hostbridge*, u32 bus, u32 devfn,
u32 reg, u32 bytes);
void (*pci_conf_write)(struct pci_hostbridge*, u32 bus, u32 devfn,
u32 reg, u32 bytes, u32 val);
};
struct pci_hostbridge{
u32 segno;
paddr_t cfg_base;
paddr_t cfg_size;
struct dt_device_node *dt_node;
struct pci_hostbridge_ops ops;
struct list_head list;
};
A PCI conf_read function would internally be as follows:
u32 pcihb_conf_read(u32 seg, u32 bus, u32 devfn,u32 reg, u32 bytes)
{
pci_hostbridge_t *pcihb;
list_for_each_entry(pcihb, pci_hostbridge_list, list)
{
if(pcihb-segno == seg)
return pcihb-ops.pci_conf_read(pcihb, bus, devfn, reg, bytes);
}
return -1;
}
Which implies 1 segment per host bridge, which doesn't seem too
nice to me: I can't see why a bridge might not cover more than one
segment, and I also can't see why you shouldn't be able to put
multiple bridges in the same segment when the number of busses
they have is small.
1 segment per host bridge is an ARM IORT requirement
(http://infocenter.arm.com/help/topic/com.arm.doc.den0049a/DEN0049A_IO_Remapping_Table.pdf).
It is also pretty much in the spirit of the MCFG table, even though it
is not spelled out so clearly there. I know that we are talking about
device tree here, but I think it is safe to keep the same constraint.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatable
On 14.08.15 at 16:37, daniel.ki...@oracle.com wrote: On Fri, Aug 14, 2015 at 08:32:05AM -0600, Jan Beulich wrote: On 14.08.15 at 15:59, daniel.ki...@oracle.com wrote: On Fri, Aug 14, 2015 at 06:49:18AM -0600, Jan Beulich wrote: On 14.08.15 at 13:52, daniel.ki...@oracle.com wrote: On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote: On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote: diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h index 87b3341..27481ac 100644 --- a/xen/include/asm-x86/page.h +++ b/xen/include/asm-x86/page.h @@ -283,7 +283,7 @@ extern root_pgentry_t idle_pg_table[ROOT_PAGETABLE_ENTRIES]; extern l2_pgentry_t *compat_idle_pg_table_l2; extern unsigned int m2p_compat_vstart; extern l2_pgentry_t l2_xenmap[L2_PAGETABLE_ENTRIES], -l2_bootmap[L2_PAGETABLE_ENTRIES]; +l2_bootmap[4*L2_PAGETABLE_ENTRIES]; ? Why do we need to expand this to be 16kB? TBH, we need 8 KiB in the worst case. The worst case is when next GiB starts (e.g. 1 GiB ends and 2 GiB starts) in the middle of Xen image. In this situation we must hook up lower l2_bootmap table with lower l3_bootmap entry, higher l2_bootmap table with higher l3_bootmap entry and finally fill l2_bootmap relevant tables in proper way. Sadly, this method requires more calculations. To avoid that I have added 3 l2_bootmap tables and simply hook up one after another with relevant l3_bootmap entries. However, if you wish we can reduce number of l2_bootmap tables to two. This way code will be more complicated but we will save about 8 KiB. Wouldn't it be better (simpler) to enforce, say, 16Mb alignment in the PE32+ header (which the EFI loader would then honor)? Good idea but then we must enforce this for multiboot protocol (v1 and v2) too. multiboot2 with my patches supports that solution. However, multiboot (v1) could be a bit problematic because it means that we must set load address to 16 MiB. Are we sure that this region is available on all machines like region starting at 1 MiB? This region being which one? 16 MiB - 32 MiB. While I think all systems where Xen can reasonably run on would have memory in that range, I'd really prefer not to touch the MB1 case (i.e. find a way for it to continue to load at 1Mb). Perhaps the 16Mb alignment could be specified only in the PE32+ header, but not enforced in the ELF one? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Empty memory nodes in VNUMA
What is the purpose of 'nr_vmemranges nr_vnodes' test in xc_domain_setvnuma()? Can't we have nodes with no memory? If that's the case, this check will still miss configurations when a node spans multiple memory ranges. For example, this fails: vcpus = 4 vnuma = [ [ pnode=0,size=2048,vcpus=0-1 ], [ pnode=1,size=1800 ], [ pnode=2,size=0,vcpus=2-3 ], [ pnode=3,size=100 ] ] but this vcpus = 4 vnuma = [ [ pnode=0,size=2048,vcpus=0-1 ], [ pnode=1,size=1801 ], [ pnode=2,size=0,vcpus=2-3 ], [ pnode=3,size=100 ] ] does not: because of MMIO hole this will cause a second 1MB range to be created on node 1 (in libxl__vnuma_build_vmemrange_hvm()). Can we drop this check? -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatable
trampoline_bios_setup: +mov %ebp,%esi + +/* Initialise GDT and basic data segments. */ +add %ebp,sym_offset(gdt_boot_descr_addr)(%esi) +lgdtsym_offset(gdt_boot_descr)(%esi) + +mov $BOOT_DS,%ecx +mov %ecx,%ds +mov %ecx,%es +mov %ecx,%fs +mov %ecx,%gs +mov %ecx,%ss + The non-EFI boot path is now: start \- __start \- multiboot2_proto |jmp trampoline_bios_setup | \-and if not MB2: jmp trampoline_bios_setup. In here you tweak the GDT and reload the %ds - but during this call chain we do touch the %ds - via: __start+27:testb $0x1,(%rbx) __start+30:cmovne 0x4(%rbx),%edx which is OK (as MB1 says that the %ds has to cover up to 4GB). But I wonder why the __start code had the segments reloaded so early? Was the bootloader not setting the proper segments? This is very good question. I was asking myself about that thing at least once. Sadly, I cannot find real explanation. Let me double-check what SYSLINUX's mboot.c32 does. Perhaps it had done something odd in the past. Good idea! Nope, the mboot.c32 COMBOOT images are booted with: %ds,%es,%fs,%gs : 32-bit data segment with zero base and 4GB limit So that is OK. Perhaps this code used to be shared with trampoline startup and got copied over. Anyhow not worried about it. .. snip.. +/* Initialize %fs and later use it to access Xen data if possible. */ +mov $BOOT_FS,%edx +mov %edx,%fs + We just modified the GDT. Should we reload it (lgdt?)? I do not think it is needed. Intel 64 and IA-32 Architectures Software Developer’s Manual, Volume 2 (2A, 2B 2C): Instruction Set Reference, A-Z says: LGDT ... Loads the values in the source operand into the global descriptor table register (GDTR)... ...and ... MOV ... If the destination operand is a segment register (DS, ES, FS, GS, or SS), the source operand must be a valid segment selector. In protected mode, moving a segment selector into a segment register automatically causes the segment descriptor information associated with that segment selector to be loaded into the hidden (shadow) part of the segment register. While loading this information, the segment .. snip.. shadow register.) When a segment selector is loaded into the visible part of a segment register, the processor also loads the hidden part of the segment register with the base address, segment limit, and access control information from the segment descriptor pointed to by the segment selector. The information cached in the segment register (visible and Excellent! hidden) allows the processor to translate addresses without taking extra bus cycles to read the base address and limit from the segment descriptor. In systems in which multiple processors have access to the same descriptor tables, it is the responsibility of software to reload the segment registers when the descriptor tables are modified (side note: GDTR reload is not required! probably the same applies to UP systems and if CPU update own active GDT). If this is not done, an old segment descriptor cached in a segment register might be used after its memory-resident version has been modified. AIUI, only GDT address and limit are loaded into GDTR when lgdt is executed. Segment descriptor is loaded directly from memory into segment register (hiden part) only when relevant load instruction is used (e.g. mov %edx,%fs). Yeey! ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4
On Fri, 14 Aug 2015, Jan Beulich wrote: On 14.08.15 at 16:45, julien.gr...@citrix.com wrote: On 14/08/15 15:37, Stefano Stabellini wrote: If you are thinking of Windows for ARM64, there isn't one yet. When/if it will become available, there are going to be a number of issues to address before we can run it as a guest on Xen on ARM with the current architecture which doesn't do emulation. I am hopeful that we'll be able to have a discussion on ABI issues such as this one. It may be worth to read [1] where the Xen ARM architecture is explained. Regards, [1] http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions_whitepaper Neither Stefano's nor your reply really make a lot of sense to me: I realize you currently require a cooperating guest, but when designing something like pass-through it would seem natural to me to try to allow for other guest kinds in the future. Xen x86 was designed to work around existing guests. In that context you had un-cooperative guests, such as Windows, and cooperative guests, such as Linux, which could be extensively modified to run on Xen. This is not the case on ARM. Please scratch all preconceptions. On ARM we only have one kind of guests: operating systems that have been ported to the published Xen ABIs. There are no legacy OSes to work around. If a new OS comes around, free or proprietary, I expect it to be ported to the Xen ABI. And that is not much of an effort, because we designed the interface from the start to be clean, nice and to make sense. Linux and FreeBSD didn't have to be extensively modified to run on Xen on ARM. This is why I am also opposed to some of your comments on ACPI for ARM, for example. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Empty memory nodes in VNUMA
On Fri, Aug 14, 2015 at 11:38:43AM -0400, Boris Ostrovsky wrote: On 08/14/2015 11:35 AM, Wei Liu wrote: On Fri, Aug 14, 2015 at 11:19:53AM -0400, Boris Ostrovsky wrote: What is the purpose of 'nr_vmemranges nr_vnodes' test in xc_domain_setvnuma()? Can't we have nodes with no memory? If that's the case, this check will still miss configurations when a node spans multiple memory ranges. For example, this fails: vcpus = 4 vnuma = [ [ pnode=0,size=2048,vcpus=0-1 ], [ pnode=1,size=1800 ], [ pnode=2,size=0,vcpus=2-3 ], [ pnode=3,size=100 ] ] but this vcpus = 4 vnuma = [ [ pnode=0,size=2048,vcpus=0-1 ], [ pnode=1,size=1801 ], [ pnode=2,size=0,vcpus=2-3 ], [ pnode=3,size=100 ] ] does not: because of MMIO hole this will cause a second 1MB range to be created on node 1 (in libxl__vnuma_build_vmemrange_hvm()). Can we drop this check? I would say yes. There is certainly such hardware that some NUMA node has 0 memory. Note that this function was written in the early day of vNUMA (4.5). I think that function has the assumption that each vnode has one vmemrange. Try removing that check and see what happens? I already did --- you think I'd ask without first trying? ;-) Yes, it works fine --- one a couple of tests that I tried. Cool. :-) Do you want me to send a patch? Sure. Much appreciated. Wei. -boris But, how far are you willing to go? Do you want system with no vmemranges at all (that means, no memory at all)? If so that nr_vmemranges == 0 check should also be removed. Just kidding... Wei. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.2-testing test] 60675: regressions - FAIL
flight 60675 xen-4.2-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/60675/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 58892 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-win7-amd64 17 guest-stop fail like 58892 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 58892 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 58892 test-amd64-i386-xl-win7-amd64 17 guest-stop fail like 58892 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-i386-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a build-i386-rumpuserxen5 rumpuserxen-buildfail never pass build-amd64-rumpuserxen 5 rumpuserxen-buildfail never pass test-i386-i386-xl-qcow2 9 debian-di-installfail never pass test-amd64-i386-xl-qcow2 9 debian-di-installfail never pass test-amd64-amd64-libvirt-qcow2 9 debian-di-installfail never pass test-amd64-i386-libvirt-qcow2 9 debian-di-installfail never pass test-i386-i386-libvirt-qcow2 9 debian-di-installfail never pass test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-amd64-amd64-pvgrub 10 guest-start fail never pass test-amd64-amd64-i386-pvgrub 10 guest-start fail never pass test-i386-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qcow2 9 debian-di-installfail never pass test-amd64-i386-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail never pass test-i386-i386-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-i386-i386-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 21 leak-check/check fail never pass test-amd64-i386-xend-qemut-winxpsp3 21 leak-check/checkfail never pass version targeted for testing: xen 32894093072c6ac5e680541669b0d1db263745fa baseline version: xen 38fcda225d6613ecc4bf44769806887252d7b2b1 Last test of basis58892 2015-06-25 05:21:03 Z 50 days Failing since 60150 2015-07-30 18:44:41 Z 15 days2 attempts Testing same since60675 2015-08-12 13:40:44 Z2 days1 attempts People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com David Scott dave.sc...@citrix.com Ian Campbell ian,campb...@citrix.com Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Jim Fehlig jfeh...@suse.com Kevin Wolf kw...@redhat.com Konrad Rzeszutek Wilk konrad.w...@oracle.com Matthew Daley mat...@gmail.com Wei Liu wei.l...@citrix.com jobs: build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xlpass 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
Re: [Xen-devel] [PATCH v1 08/10] xen/pt: Make xen_pt_unregister_device idempotent
@@ -818,10 +819,13 @@ static void xen_pt_unregister_device(PCIDevice *d)
{
XenPCIPassthroughState *s = XEN_PT_DEVICE(d);
uint8_t machine_irq = s-machine_irq;
-uint8_t intx = xen_pt_pci_intx(s);
+uint8_t intx;
int rc;
-if (machine_irq) {
+ /* Note that if xen_host_pci_device_put had closed config_fd, then
+ * intx value becomes 0xff. */
+intx = xen_pt_pci_intx(s);
Wouldn't it make sense to move this assignment inside the if below?
Totally. Plus it also allows me to remove the comment above.
Aside from this small item:
Reviewed-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
Thank you.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen-unstable Linux 4.2-rc6: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 51s! xen_hypercall_xen_version+0xa/0x20
Friday, August 14, 2015, 8:11:10 PM, you wrote: Hi, At the moment i'm encounterig this new splat in a PV guest, both dom0 and domU running a kernel 4.2-rc6 (last commit 7ddab73346a1277b90fd6a4d044bc948f9cc9ad8) and xen-unstable (last commit git:201eac8-dirty) -- Sander Edit: it was clearly running rc6 not rc5. NMI watchdog: BUG: soft lockup - CPU#0 stuck for 51s! [swapper/0:0] [14410.728735] Modules linked in: [14410.728735] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc6-20150814-linus-doflr+ #1 [14410.728735] task: 8221a580 ti: 8220 task.ti: 8220 [14410.728735] RIP: e030:[8100122a] [8100122a] xen_hypercall_xen_version+0xa/0x20 [14410.728735] RSP: e02b:88000fc03d48 EFLAGS: 0246 [14410.728735] RAX: 00040006 RBX: 0200 RCX: 8100122a [14410.728735] RDX: 0001 RSI: deadbeef RDI: deadbeef [14410.728735] RBP: 88000fc03d60 R08: 88000fc03ee0 R09: [14410.728735] R10: 8220a0c0 R11: 0246 R12: [14410.728735] R13: 0001 R14: 88000e3faedc R15: 0005 [14410.728735] FS: 7f71f50e2800() GS:88000fc0() knlGS: [14410.728735] CS: e033 DS: ES: CR0: 8005003b [14410.728735] CR2: 7fffaef93808 CR3: 0309 CR4: 0660 [14410.728735] Stack: [14410.728735] 0020 0007 81008dbd 88000fc03dd8 [14410.728735] 81009592 0020 8220a0c0 [14410.728735] 88000fc03ee0 0200 0200 0001 [14410.728735] Call Trace: [14410.728735] IRQ [14410.728735] [81008dbd] ? xen_force_evtchn_callback+0xd/0x10 [14410.728735] [81009592] check_events+0x12/0x20 [14410.728735] [8100957f] ? xen_restore_fl_direct_reloc+0x4/0x4 [14410.728735] [81af78a5] ? _raw_spin_unlock_irqrestore+0x25/0x30 [14410.728735] [8110ed03] try_to_del_timer_sync+0x43/0x60 [14410.728735] [8110ed67] del_timer_sync+0x47/0x60 [14410.728735] [81a2b598] inet_csk_reqsk_queue_drop+0x118/0x1f0 [14410.728735] [81a2b7c6] reqsk_timer_handler+0x156/0x260 [14410.728735] [81a2b670] ? inet_csk_reqsk_queue_drop+0x1f0/0x1f0 [14410.728735] [8110f387] call_timer_fn.isra.27+0x17/0x80 [14410.728735] [81a2b670] ? inet_csk_reqsk_queue_drop+0x1f0/0x1f0 [14410.728735] [8110f51d] run_timer_softirq+0x12d/0x200 [14410.728735] [810ca6c3] __do_softirq+0x103/0x210 [14410.728735] [810ca9cb] irq_exit+0x4b/0xa0 [14410.728735] [814f04d4] xen_evtchn_do_upcall+0x34/0x50 [14410.728735] [81af922e] xen_do_hypervisor_callback+0x1e/0x40 [14410.728735] EOI [14410.728735] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [14410.728735] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [14410.728735] [81008d60] ? xen_safe_halt+0x10/0x20 [14410.728735] [810188d3] ? default_idle+0x13/0x20 [14410.728735] [81018e1a] ? arch_cpu_idle+0xa/0x10 [14410.728735] [810f8e7e] ? default_idle_call+0x2e/0x50 [14410.728735] [810f9112] ? cpu_startup_entry+0x272/0x2e0 [14410.728735] [81ae7867] ? rest_init+0x77/0x80 [14410.728735] [82312f58] ? start_kernel+0x43b/0x448 [14410.728735] [823124ef] ? x86_64_start_reservations+0x2a/0x2c [14410.728735] [82316008] ? xen_start_kernel+0x550/0x55c [14410.728735] Code: cc 51 41 53 b8 10 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 11 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4
How about having a short discussion on Monday during Xen Summit to discuss on
the points.
We have a talk tuesday morning and I would update it based on the monday
discussion.
Regards,
Manish Jaggi
From: xen-devel-boun...@lists.xen.org xen-devel-boun...@lists.xen.org on
behalf of Stefano Stabellini stefano.stabell...@eu.citrix.com
Sent: Friday, August 14, 2015 9:08 PM
To: Jan Beulich
Cc: prasun.kap...@cavium.com; Ian Campbell; stefano.stabell...@eu.citrix.com;
Jaggi, Manish; Kumar, Vijaya; Julien Grall; Xen Devel
Subject: Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4
On Thu, 13 Aug 2015, Jan Beulich wrote:
On 13.08.15 at 11:42, mja...@caviumnetworks.com wrote:
2.1pci_hostbridge and pci_hostbridge_ops
-
The init function in the PCI host driver calls to register hostbridge
callbacks:
int pci_hostbridge_register(pci_hostbridge_t *pcihb);
struct pci_hostbridge_ops {
u32 (*pci_conf_read)(struct pci_hostbridge*, u32 bus, u32 devfn,
u32 reg, u32 bytes);
void (*pci_conf_write)(struct pci_hostbridge*, u32 bus, u32 devfn,
u32 reg, u32 bytes, u32 val);
};
struct pci_hostbridge{
u32 segno;
paddr_t cfg_base;
paddr_t cfg_size;
struct dt_device_node *dt_node;
struct pci_hostbridge_ops ops;
struct list_head list;
};
A PCI conf_read function would internally be as follows:
u32 pcihb_conf_read(u32 seg, u32 bus, u32 devfn,u32 reg, u32 bytes)
{
pci_hostbridge_t *pcihb;
list_for_each_entry(pcihb, pci_hostbridge_list, list)
{
if(pcihb-segno == seg)
return pcihb-ops.pci_conf_read(pcihb, bus, devfn, reg, bytes);
}
return -1;
}
Which implies 1 segment per host bridge, which doesn't seem too
nice to me: I can't see why a bridge might not cover more than one
segment, and I also can't see why you shouldn't be able to put
multiple bridges in the same segment when the number of busses
they have is small.
1 segment per host bridge is an ARM IORT requirement
(http://infocenter.arm.com/help/topic/com.arm.doc.den0049a/DEN0049A_IO_Remapping_Table.pdf).
It is also pretty much in the spirit of the MCFG table, even though it
is not spelled out so clearly there. I know that we are talking about
device tree here, but I think it is safe to keep the same constraint.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] About Xen bridged pci devices and suspend/resume for the X10SAE motherboard (SuperMicro)
On Fri, Aug 14, 2015 at 05:08:32PM +0300, M. Ivanov wrote: On Thu, 2015-08-13 at 15:49 -0400, Konrad Rzeszutek Wilk wrote: On Mon, Aug 10, 2015 at 09:21:35PM +0300, M. Ivanov wrote: On Mon, 2015-08-10 at 10:47 -0400, Konrad Rzeszutek Wilk wrote: On Mon, Aug 10, 2015 at 05:14:28PM +0300, M. Ivanov wrote: On Mon, 2015-08-10 at 09:58 -0400, Konrad Rzeszutek Wilk wrote: On Mon, Aug 10, 2015 at 02:11:38AM +0300, M. Ivanov wrote: Hello, excuse me for bothering you, but I've read an old thread on a mailing list about X10SAE compatibility. http://lists.xen.org/archives/html/xen-devel/2014-02/msg02111.html CC-ing Xen devel. Currently I own this board and am trying to use it with Xen and be able to suspend and resume. But I am getting errors from the USB 3 Renesas controller about parity in my bios event log, and my system hangs on resume, so I was wondering if that is connected to the bridge(tundra) you've mentioned. Did you update the BIOS to the latest version? Will updating to version 3 solve my issue? Can you do a suspend/resume on your X10SAE? It did work at some point. I will find out when I am at home later today. Looking forward to your reply and am really thankful for your time, so far I've tried changing many of the settings in the bios, fiddling with Xen's kernel params, blacklisting the xhci driver, doing a xl detach. The only thing I haven't done yet is updating the bios, but Supermicro's support couldn't give me a changelog: The primary objective for ver3.0 BIOS release is to support Intel Broadwell CPUs We do not know if BIOS update will fix the issue you are seeing as we never tested it with Xen. I did test it remotely and it did something very odd. It suspended and then immediately resumed with tons of VT-d errors!? I will try again but be actually right by it. Thanks for your effort, Can you suggest a way for me to log what is happening? I usually have an serial cable attached to it and log that. Cranking up the debug on everything gives me some idea. Since my machine just hangs up and I don't get a picture on the screen. Or when I do(sometimes) - it's just a cursor,(on a black screen with nothing else,no errors shown) and the machine doesn't react to any key combinations. Yeah. That is frustrating. On a side note: I did try updating the bios, but got some really strange result. The first time I got checksums about everything OK, (erase,flash,verify), but then it said - FDT is locked! And I am at least 90% sure I've enabled reflash in the BIOS setup prior to flashing. So I've restarted but didn't clear the CMOS(through the jumper on the board). And it said Bios v 3.0 in the setup, then I also did the Reset to optmized defaults. Tried suspending and couldn't resume like always. But perhaps currently my BIOS is in a broken/corrupted state. After that I've tried reflashing the bios again. But this time - after the messages about Erasing,Flashing,Verifying: it just froze. I didn't get any message about FDT, restarting or whatsoever. So I rebooted and it seems to work like before, says version 3.0 in the BIOS setup. I wonder if I should try clearing the CMOS and flashing again. One test I hadn't done is to try to suspend/resume under baremental Linux and see how that works. Does it work for you? The DMI tells me: [7.276963] Hardware name: Supermicro X10SAE/X10SAE, BIOS 2.00 04/21/2014 So a bit older BIOS. The last thing I see: # dmesg | grep -i Super [0.00] DMI: Supermicro X10SAE/X10SAE, BIOS 2.00 04/21/2014 [0.00] ACPI: RSDP 0x000F0490 24 (v02-MB 01072009 AMI 00010013) [0.00] ACPI: DSDT 0x9B9DA1E8 00CDDA (v02 SUPERM SMCI--MB INTL 20120711) [0.00] ACPI: APIC 0x9B9E70D8 92 (v03 SUPERM SMCI--MB 01072009 AMI 00010013) [0.00] ACPI: FPDT 0x9B9E7170 44 (v01 SUPERM SMCI--MB 01072009 AMI 00010013) [0.00] ACPI: MCFG 0x9B9E9488 3C (v01 SUPERM SMCI--MB 01072009 MSFT 0097) [0.00] ACPI: HPET 0x9B9E94C8 38 (v01 SUPERM SMCI--MB 01072009 AMI. 0005) [7.623166] Hardware name: Supermicro X10SAE/X10SAE, BIOS 2.00 04/21/2014 # pm-suspoe # [Jcd /sys/power # ls diskpm_freeze_timeout pm_traceresume image_size pm_print_times pm_trace_dev_match state pm_asyncpm_testreserved_size wakeup_count # c# [Jcat state freeze standby disk # echo standby state [ 204.755164] PM: Syncing filesystems ... done. [ 204.755223] PM: Preparing system for standby sleep [ 204.755606] Freezing user space processes ... (elapsed 0.000 seconds) done. [ 204.756506] Freezing reĂ½+Ă‹+Ă‹Â•Ă¿ezable tasks
[Xen-devel] [PATCH 3.10 17/35] x86/xen: Probe target addresses in set_aliased_prot() before the hypercall
3.10-stable review patch. If anyone has any objections, please let me know. -- From: Andy Lutomirski l...@kernel.org commit aa1acff356bbedfd03b544051f5b371746735d89 upstream. The update_va_mapping hypercall can fail if the VA isn't present in the guest's page tables. Under certain loads, this can result in an OOPS when the target address is in unpopulated vmap space. While we're at it, add comments to help explain what's going on. This isn't a great long-term fix. This code should probably be changed to use something like set_memory_ro. Signed-off-by: Andy Lutomirski l...@kernel.org Cc: Andrew Cooper andrew.coop...@citrix.com Cc: Andy Lutomirski l...@amacapital.net Cc: Boris Ostrovsky boris.ostrov...@oracle.com Cc: Borislav Petkov b...@alien8.de Cc: Brian Gerst brge...@gmail.com Cc: David Vrabel dvra...@cantab.net Cc: Denys Vlasenko dvlas...@redhat.com Cc: H. Peter Anvin h...@zytor.com Cc: Jan Beulich jbeul...@suse.com Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com Cc: Linus Torvalds torva...@linux-foundation.org Cc: Peter Zijlstra pet...@infradead.org Cc: Sasha Levin sasha.le...@oracle.com Cc: Steven Rostedt rost...@goodmis.org Cc: Thomas Gleixner t...@linutronix.de Cc: secur...@kernel.org secur...@kernel.org Cc: xen-devel xen-devel@lists.xen.org Link: http://lkml.kernel.org/r/0b0e55b995cda11e7829f140b833ef932fcabe3a.1438291540.git.l...@kernel.org Signed-off-by: Ingo Molnar mi...@kernel.org Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- arch/x86/xen/enlighten.c | 40 1 file changed, 40 insertions(+) --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -481,6 +481,7 @@ static void set_aliased_prot(void *v, pg pte_t pte; unsigned long pfn; struct page *page; + unsigned char dummy; ptep = lookup_address((unsigned long)v, level); BUG_ON(ptep == NULL); @@ -490,6 +491,32 @@ static void set_aliased_prot(void *v, pg pte = pfn_pte(pfn, prot); + /* +* Careful: update_va_mapping() will fail if the virtual address +* we're poking isn't populated in the page tables. We don't +* need to worry about the direct map (that's always in the page +* tables), but we need to be careful about vmap space. In +* particular, the top level page table can lazily propagate +* entries between processes, so if we've switched mms since we +* vmapped the target in the first place, we might not have the +* top-level page table entry populated. +* +* We disable preemption because we want the same mm active when +* we probe the target and when we issue the hypercall. We'll +* have the same nominal mm, but if we're a kernel thread, lazy +* mm dropping could change our pgd. +* +* Out of an abundance of caution, this uses __get_user() to fault +* in the target address just in case there's some obscure case +* in which the target address isn't readable. +*/ + + preempt_disable(); + + pagefault_disable();/* Avoid warnings due to being atomic. */ + __get_user(dummy, (unsigned char __user __force *)v); + pagefault_enable(); + if (HYPERVISOR_update_va_mapping((unsigned long)v, pte, 0)) BUG(); @@ -501,6 +528,8 @@ static void set_aliased_prot(void *v, pg BUG(); } else kmap_flush_unused(); + + preempt_enable(); } static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries) @@ -508,6 +537,17 @@ static void xen_alloc_ldt(struct desc_st const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE; int i; + /* +* We need to mark the all aliases of the LDT pages RO. We +* don't need to call vm_flush_aliases(), though, since that's +* only responsible for flushing aliases out the TLBs, not the +* page tables, and Xen will flush the TLB for us if needed. +* +* To avoid confusing future readers: none of this is necessary +* to load the LDT. The hypervisor only checks this when the +* LDT is faulted in due to subsequent descriptor access. +*/ + for(i = 0; i entries; i += entries_per_page) set_aliased_prot(ldt + i, PAGE_KERNEL_RO); } ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3.14 18/44] x86/xen: Probe target addresses in set_aliased_prot() before the hypercall
3.14-stable review patch. If anyone has any objections, please let me know. -- From: Andy Lutomirski l...@kernel.org commit aa1acff356bbedfd03b544051f5b371746735d89 upstream. The update_va_mapping hypercall can fail if the VA isn't present in the guest's page tables. Under certain loads, this can result in an OOPS when the target address is in unpopulated vmap space. While we're at it, add comments to help explain what's going on. This isn't a great long-term fix. This code should probably be changed to use something like set_memory_ro. Signed-off-by: Andy Lutomirski l...@kernel.org Cc: Andrew Cooper andrew.coop...@citrix.com Cc: Andy Lutomirski l...@amacapital.net Cc: Boris Ostrovsky boris.ostrov...@oracle.com Cc: Borislav Petkov b...@alien8.de Cc: Brian Gerst brge...@gmail.com Cc: David Vrabel dvra...@cantab.net Cc: Denys Vlasenko dvlas...@redhat.com Cc: H. Peter Anvin h...@zytor.com Cc: Jan Beulich jbeul...@suse.com Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com Cc: Linus Torvalds torva...@linux-foundation.org Cc: Peter Zijlstra pet...@infradead.org Cc: Sasha Levin sasha.le...@oracle.com Cc: Steven Rostedt rost...@goodmis.org Cc: Thomas Gleixner t...@linutronix.de Cc: secur...@kernel.org secur...@kernel.org Cc: xen-devel xen-devel@lists.xen.org Link: http://lkml.kernel.org/r/0b0e55b995cda11e7829f140b833ef932fcabe3a.1438291540.git.l...@kernel.org Signed-off-by: Ingo Molnar mi...@kernel.org Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- arch/x86/xen/enlighten.c | 40 1 file changed, 40 insertions(+) --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -481,6 +481,7 @@ static void set_aliased_prot(void *v, pg pte_t pte; unsigned long pfn; struct page *page; + unsigned char dummy; ptep = lookup_address((unsigned long)v, level); BUG_ON(ptep == NULL); @@ -490,6 +491,32 @@ static void set_aliased_prot(void *v, pg pte = pfn_pte(pfn, prot); + /* +* Careful: update_va_mapping() will fail if the virtual address +* we're poking isn't populated in the page tables. We don't +* need to worry about the direct map (that's always in the page +* tables), but we need to be careful about vmap space. In +* particular, the top level page table can lazily propagate +* entries between processes, so if we've switched mms since we +* vmapped the target in the first place, we might not have the +* top-level page table entry populated. +* +* We disable preemption because we want the same mm active when +* we probe the target and when we issue the hypercall. We'll +* have the same nominal mm, but if we're a kernel thread, lazy +* mm dropping could change our pgd. +* +* Out of an abundance of caution, this uses __get_user() to fault +* in the target address just in case there's some obscure case +* in which the target address isn't readable. +*/ + + preempt_disable(); + + pagefault_disable();/* Avoid warnings due to being atomic. */ + __get_user(dummy, (unsigned char __user __force *)v); + pagefault_enable(); + if (HYPERVISOR_update_va_mapping((unsigned long)v, pte, 0)) BUG(); @@ -501,6 +528,8 @@ static void set_aliased_prot(void *v, pg BUG(); } else kmap_flush_unused(); + + preempt_enable(); } static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries) @@ -508,6 +537,17 @@ static void xen_alloc_ldt(struct desc_st const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE; int i; + /* +* We need to mark the all aliases of the LDT pages RO. We +* don't need to call vm_flush_aliases(), though, since that's +* only responsible for flushing aliases out the TLBs, not the +* page tables, and Xen will flush the TLB for us if needed. +* +* To avoid confusing future readers: none of this is necessary +* to load the LDT. The hypervisor only checks this when the +* LDT is faulted in due to subsequent descriptor access. +*/ + for(i = 0; i entries; i += entries_per_page) set_aliased_prot(ldt + i, PAGE_KERNEL_RO); } ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-4.6] xl/vNUMA: Allow empty memory nodes
The test for 'nr_vmemranges nr_vnodes' in xc_domain_setvnuma() was originally writtten with the idea that number of memory ranges would at least be equal to number of nodes. We may want to specify nodes with no memory, however, and thus this check should be removed. Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com --- tools/libxc/xc_domain.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c index 2ee26fb..780797f 100644 --- a/tools/libxc/xc_domain.c +++ b/tools/libxc/xc_domain.c @@ -2451,8 +2451,7 @@ int xc_domain_setvnuma(xc_interface *xch, XC_HYPERCALL_BUFFER_BOUNCE_BOTH); errno = EINVAL; -if ( nr_vnodes == 0 || nr_vmemranges == 0 || - nr_vmemranges nr_vnodes || nr_vcpus == 0 ) +if ( nr_vnodes == 0 || nr_vmemranges == 0 || nr_vcpus == 0 ) return -1; if ( !vdistance || !vcpu_to_vnode || !vmemrange || !vnode_to_pnode ) -- 1.9.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 4.1 50/84] x86/xen: Probe target addresses in set_aliased_prot() before the hypercall
4.1-stable review patch. If anyone has any objections, please let me know. -- From: Andy Lutomirski l...@kernel.org commit aa1acff356bbedfd03b544051f5b371746735d89 upstream. The update_va_mapping hypercall can fail if the VA isn't present in the guest's page tables. Under certain loads, this can result in an OOPS when the target address is in unpopulated vmap space. While we're at it, add comments to help explain what's going on. This isn't a great long-term fix. This code should probably be changed to use something like set_memory_ro. Signed-off-by: Andy Lutomirski l...@kernel.org Cc: Andrew Cooper andrew.coop...@citrix.com Cc: Andy Lutomirski l...@amacapital.net Cc: Boris Ostrovsky boris.ostrov...@oracle.com Cc: Borislav Petkov b...@alien8.de Cc: Brian Gerst brge...@gmail.com Cc: David Vrabel dvra...@cantab.net Cc: Denys Vlasenko dvlas...@redhat.com Cc: H. Peter Anvin h...@zytor.com Cc: Jan Beulich jbeul...@suse.com Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com Cc: Linus Torvalds torva...@linux-foundation.org Cc: Peter Zijlstra pet...@infradead.org Cc: Sasha Levin sasha.le...@oracle.com Cc: Steven Rostedt rost...@goodmis.org Cc: Thomas Gleixner t...@linutronix.de Cc: secur...@kernel.org secur...@kernel.org Cc: xen-devel xen-devel@lists.xen.org Link: http://lkml.kernel.org/r/0b0e55b995cda11e7829f140b833ef932fcabe3a.1438291540.git.l...@kernel.org Signed-off-by: Ingo Molnar mi...@kernel.org Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- arch/x86/xen/enlighten.c | 40 1 file changed, 40 insertions(+) --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -483,6 +483,7 @@ static void set_aliased_prot(void *v, pg pte_t pte; unsigned long pfn; struct page *page; + unsigned char dummy; ptep = lookup_address((unsigned long)v, level); BUG_ON(ptep == NULL); @@ -492,6 +493,32 @@ static void set_aliased_prot(void *v, pg pte = pfn_pte(pfn, prot); + /* +* Careful: update_va_mapping() will fail if the virtual address +* we're poking isn't populated in the page tables. We don't +* need to worry about the direct map (that's always in the page +* tables), but we need to be careful about vmap space. In +* particular, the top level page table can lazily propagate +* entries between processes, so if we've switched mms since we +* vmapped the target in the first place, we might not have the +* top-level page table entry populated. +* +* We disable preemption because we want the same mm active when +* we probe the target and when we issue the hypercall. We'll +* have the same nominal mm, but if we're a kernel thread, lazy +* mm dropping could change our pgd. +* +* Out of an abundance of caution, this uses __get_user() to fault +* in the target address just in case there's some obscure case +* in which the target address isn't readable. +*/ + + preempt_disable(); + + pagefault_disable();/* Avoid warnings due to being atomic. */ + __get_user(dummy, (unsigned char __user __force *)v); + pagefault_enable(); + if (HYPERVISOR_update_va_mapping((unsigned long)v, pte, 0)) BUG(); @@ -503,6 +530,8 @@ static void set_aliased_prot(void *v, pg BUG(); } else kmap_flush_unused(); + + preempt_enable(); } static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries) @@ -510,6 +539,17 @@ static void xen_alloc_ldt(struct desc_st const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE; int i; + /* +* We need to mark the all aliases of the LDT pages RO. We +* don't need to call vm_flush_aliases(), though, since that's +* only responsible for flushing aliases out the TLBs, not the +* page tables, and Xen will flush the TLB for us if needed. +* +* To avoid confusing future readers: none of this is necessary +* to load the LDT. The hypervisor only checks this when the +* LDT is faulted in due to subsequent descriptor access. +*/ + for(i = 0; i entries; i += entries_per_page) set_aliased_prot(ldt + i, PAGE_KERNEL_RO); } ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Xen-unstable Linux 4.2-rc5: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 51s! xen_hypercall_xen_version+0xa/0x20
Hi, At the moment i'm encounterig this new splat in a PV guest, both dom0 and domU running a kernel 4.2-rc5 (last commit 7ddab73346a1277b90fd6a4d044bc948f9cc9ad8) and xen-unstable (last commit git:201eac8-dirty) -- Sander NMI watchdog: BUG: soft lockup - CPU#0 stuck for 51s! [swapper/0:0] [14410.728735] Modules linked in: [14410.728735] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc6-20150814-linus-doflr+ #1 [14410.728735] task: 8221a580 ti: 8220 task.ti: 8220 [14410.728735] RIP: e030:[8100122a] [8100122a] xen_hypercall_xen_version+0xa/0x20 [14410.728735] RSP: e02b:88000fc03d48 EFLAGS: 0246 [14410.728735] RAX: 00040006 RBX: 0200 RCX: 8100122a [14410.728735] RDX: 0001 RSI: deadbeef RDI: deadbeef [14410.728735] RBP: 88000fc03d60 R08: 88000fc03ee0 R09: [14410.728735] R10: 8220a0c0 R11: 0246 R12: [14410.728735] R13: 0001 R14: 88000e3faedc R15: 0005 [14410.728735] FS: 7f71f50e2800() GS:88000fc0() knlGS: [14410.728735] CS: e033 DS: ES: CR0: 8005003b [14410.728735] CR2: 7fffaef93808 CR3: 0309 CR4: 0660 [14410.728735] Stack: [14410.728735] 0020 0007 81008dbd 88000fc03dd8 [14410.728735] 81009592 0020 8220a0c0 [14410.728735] 88000fc03ee0 0200 0200 0001 [14410.728735] Call Trace: [14410.728735] IRQ [14410.728735] [81008dbd] ? xen_force_evtchn_callback+0xd/0x10 [14410.728735] [81009592] check_events+0x12/0x20 [14410.728735] [8100957f] ? xen_restore_fl_direct_reloc+0x4/0x4 [14410.728735] [81af78a5] ? _raw_spin_unlock_irqrestore+0x25/0x30 [14410.728735] [8110ed03] try_to_del_timer_sync+0x43/0x60 [14410.728735] [8110ed67] del_timer_sync+0x47/0x60 [14410.728735] [81a2b598] inet_csk_reqsk_queue_drop+0x118/0x1f0 [14410.728735] [81a2b7c6] reqsk_timer_handler+0x156/0x260 [14410.728735] [81a2b670] ? inet_csk_reqsk_queue_drop+0x1f0/0x1f0 [14410.728735] [8110f387] call_timer_fn.isra.27+0x17/0x80 [14410.728735] [81a2b670] ? inet_csk_reqsk_queue_drop+0x1f0/0x1f0 [14410.728735] [8110f51d] run_timer_softirq+0x12d/0x200 [14410.728735] [810ca6c3] __do_softirq+0x103/0x210 [14410.728735] [810ca9cb] irq_exit+0x4b/0xa0 [14410.728735] [814f04d4] xen_evtchn_do_upcall+0x34/0x50 [14410.728735] [81af922e] xen_do_hypervisor_callback+0x1e/0x40 [14410.728735] EOI [14410.728735] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [14410.728735] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [14410.728735] [81008d60] ? xen_safe_halt+0x10/0x20 [14410.728735] [810188d3] ? default_idle+0x13/0x20 [14410.728735] [81018e1a] ? arch_cpu_idle+0xa/0x10 [14410.728735] [810f8e7e] ? default_idle_call+0x2e/0x50 [14410.728735] [810f9112] ? cpu_startup_entry+0x272/0x2e0 [14410.728735] [81ae7867] ? rest_init+0x77/0x80 [14410.728735] [82312f58] ? start_kernel+0x43b/0x448 [14410.728735] [823124ef] ? x86_64_start_reservations+0x2a/0x2c [14410.728735] [82316008] ? xen_start_kernel+0x550/0x55c [14410.728735] Code: cc 51 41 53 b8 10 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 11 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen: arm: Support 32MB frametables
Hi Julien, Thanks for the review. /* Create Xen's mappings of memory. - * Base and virt must be 32MB aligned and size a multiple of 32MB. + * Mapping_size must be either 2MB or 32MB. I would have generalize the function to support any mapping size. But I'm also fine with the current solution. The code would have to be (somewhat) more complex to do that. I think I prefer to keep it simple for now. +const unsigned long granularity = mapping_size PAGE_SHIFT; This variable is only used in the ASSERT. On non-debug build the compiler will throw an error because the variable will be unused. Good point. Will fix. +if ( mapping_size == MB(32) ) +pte.pt.contig = 1; /* These maps are in 16-entry contiguous + chunks. */ mfn_to_xen_entry never set the contig bit to 0 (or anything else). So the value will be undefined for MB(2) mapping. It looks like to me that mfn_to_xen_entry should always set the contig bit to 0. I'm not sure why we didn't see any issue until now. Can you please send a patch for this? Will do. Chris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.6] xl/vNUMA: Allow empty memory nodes
This title should say libxc: ... On Fri, Aug 14, 2015 at 12:18:52PM -0400, Boris Ostrovsky wrote: The test for 'nr_vmemranges nr_vnodes' in xc_domain_setvnuma() was originally writtten with the idea that number of memory ranges would at least be equal to number of nodes. We may want to specify nodes with no memory, however, and thus this check should be removed. Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com Acked-by: Wei Liu wei.l...@citrix.com With my RM hat on, because libxl, hypervisor and hvmloader can already cope with 0 vmemrange configuration, removing this restriction is safe. Release-acked-by: Wei Liu wei.l...@citrix.com --- tools/libxc/xc_domain.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c index 2ee26fb..780797f 100644 --- a/tools/libxc/xc_domain.c +++ b/tools/libxc/xc_domain.c @@ -2451,8 +2451,7 @@ int xc_domain_setvnuma(xc_interface *xch, XC_HYPERCALL_BUFFER_BOUNCE_BOTH); errno = EINVAL; -if ( nr_vnodes == 0 || nr_vmemranges == 0 || - nr_vmemranges nr_vnodes || nr_vcpus == 0 ) +if ( nr_vnodes == 0 || nr_vmemranges == 0 || nr_vcpus == 0 ) return -1; if ( !vdistance || !vcpu_to_vnode || !vmemrange || !vnode_to_pnode ) -- 1.9.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.6] xl/vNUMA: Allow empty memory nodes
On 08/14/2015 12:26 PM, Wei Liu wrote: This title should say libxc: ... Ah, of course. Let me know if you want me to re-send it. -boris On Fri, Aug 14, 2015 at 12:18:52PM -0400, Boris Ostrovsky wrote: The test for 'nr_vmemranges nr_vnodes' in xc_domain_setvnuma() was originally writtten with the idea that number of memory ranges would at least be equal to number of nodes. We may want to specify nodes with no memory, however, and thus this check should be removed. Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com Acked-by: Wei Liu wei.l...@citrix.com With my RM hat on, because libxl, hypervisor and hvmloader can already cope with 0 vmemrange configuration, removing this restriction is safe. Release-acked-by: Wei Liu wei.l...@citrix.com --- tools/libxc/xc_domain.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c index 2ee26fb..780797f 100644 --- a/tools/libxc/xc_domain.c +++ b/tools/libxc/xc_domain.c @@ -2451,8 +2451,7 @@ int xc_domain_setvnuma(xc_interface *xch, XC_HYPERCALL_BUFFER_BOUNCE_BOTH); errno = EINVAL; -if ( nr_vnodes == 0 || nr_vmemranges == 0 || - nr_vmemranges nr_vnodes || nr_vcpus == 0 ) +if ( nr_vnodes == 0 || nr_vmemranges == 0 || nr_vcpus == 0 ) return -1; if ( !vdistance || !vcpu_to_vnode || !vmemrange || !vnode_to_pnode ) -- 1.9.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Patch x86/ldt: Make modify_ldt synchronous has been added to the 4.1-stable tree
On Fri, Aug 14, 2015 at 12:16 AM, Ingo Molnar mi...@kernel.org wrote: I just sent it to Linus, so barring a catastrophy it should be upstream soon. Well, I just rejected that pull as completely broken, so I guess the catastrophy happened... Or, alternatively, I mis-read the code, which does happen, but my giant ego tells me that's very rare.. Linus ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/2] xen: arm: Ensure all PTE bits have a known value
Hi, This is more-or-less what Julien requested. He noted that pt.contig was never set to zero. When I looked further, I found other bits that were also never given a value. Looking at the callsites, they almost all seem to assume a value of zero, so that's what I went with. Patch 1 re-orders the assignments to match the declaration, making it clearer which ones are missing. Patch 2 then adds the missing bits. Chris P.S. Apologies for any threading issues - I have not yet managed to get git send-email working properly. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] xen: arm re-order assignments in mfn_to_xen_entry()
Shuffle lines around so that the assignments in mfn_to_xen_entry()
occur in the same order as the bits are declared in lpae_pt_t.
This makes it easier to see which ones are never given a value.
No change in behaviour.
Also fix a minor comment typo.
Signed-off-by: Chris Brand chris.br...@broadcom.com
---
xen/include/asm-arm/page.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 5ecfd0705e07..01628f3e96cb 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -197,18 +197,18 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn,
unsigned attr)
paddr_t pa = ((paddr_t) mfn) PAGE_SHIFT;
lpae_t e = (lpae_t) {
.pt = {
-.xn = 1, /* No need to execute outside .text */
-.ng = 1, /* Makes TLB flushes easier */
-.af = 1, /* No need for access tracking */
+.valid = 1, /* Mappings are present */
+.table = 0, /* Set to 1 for links and 4k maps */
+.ai = attr,
.ns = 1, /* Hyp mode is in the non-secure world */
.user = 1,/* See below */
-.ai = attr,
-.table = 0, /* Set to 1 for links and 4k maps */
-.valid = 1, /* Mappings are present */
+.af = 1, /* No need for access tracking */
+.ng = 1, /* Makes TLB flushes easier */
+.xn = 1, /* No need to execute outside .text */
}};;
/* Setting the User bit is strange, but the ATS1H[RW] instructions
* don't seem to work otherwise, and since we never run on Xen
- * pagetables un User mode it's OK. If this changes, remember
+ * pagetables in User mode it's OK. If this changes, remember
* to update the hard-coded values in head.S too */
switch ( attr )
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/2] xen: arm: Ensure all PTE bits have a known value
Hi, This is more-or-less what Julien requested. He noted that pt.contig was never set to zero. When I looked further, I found other bits that were also never given a value. Looking at the callsites, they almost all seem to assume a value of zero, so that's what I went with. Patch 1 re-orders the assignments to match the declaration, making it clearer which ones are missing. Patch 2 then adds the missing bits. Chris P.S. Apologies for any threading issues - I have not yet managed to get git send-email working properly. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
On 2015-08-13 00:41, Eric Dumazet wrote: On Wed, 2015-08-12 at 23:46 +0200, Sander Eikelenboom wrote: Thanks for the reminder, but luckily i was aware of that, seen enough of your replies asking for patches to be resubmitted against the other tree ;) Kernel with patch is currently running so fingers crossed. Thanks for testing. I am definitely interested knowing your results. Hmm it seems now commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af is breaking things (have to test if a revert helps) i get this in some guests: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 506s! [swapper/0:0] [ 6620.282805] Modules linked in: [ 6620.282805] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc6-20150814-linus-doflr-apicrevert+ #1 [ 6620.282805] task: 8221a580 ti: 8220 task.ti: 8220 [ 6620.282805] RIP: e030:[8100122a] [8100122a] xen_hypercall_xen_version+0xa/0x20 [ 6620.282805] RSP: e02b:88000fc03d48 EFLAGS: 0246 [ 6620.282805] RAX: 00040006 RBX: 0200 RCX: 8100122a [ 6620.282805] RDX: 0001 RSI: deadbeef RDI: deadbeef [ 6620.282805] RBP: 88000fc03d60 R08: 88000fc03ee0 R09: 00ee [ 6620.282805] R10: 8220a0c0 R11: 0246 R12: [ 6620.282805] R13: 0001 R14: 880003b53054 R15: 0005 [ 6620.282805] FS: 7fec747ad800() GS:88000fc0() knlGS: [ 6620.282805] CS: e033 DS: ES: CR0: 8005003b [ 6620.282805] CR2: 7ffcb7a7a6d8 CR3: 03164000 CR4: 0660 [ 6620.282805] Stack: [ 6620.282805] 0068 0007 81008dbd 88000fc03dd8 [ 6620.282805] 81009592 0068 8220a0c0 00ee [ 6620.282805] 88000fc03ee0 0200 0200 0001 [ 6620.282805] Call Trace: [ 6620.282805] IRQ [ 6620.282805] [81008dbd] ? xen_force_evtchn_callback+0xd/0x10 [ 6620.282805] [81009592] check_events+0x12/0x20 [ 6620.282805] [8100957f] ? xen_restore_fl_direct_reloc+0x4/0x4 [ 6620.282805] [81af79a5] ? _raw_spin_unlock_irqrestore+0x25/0x30 [ 6620.282805] [8110ed43] try_to_del_timer_sync+0x43/0x60 [ 6620.282805] [8110eda7] del_timer_sync+0x47/0x60 [ 6620.282805] [81a2b698] inet_csk_reqsk_queue_drop+0x118/0x1f0 [ 6620.282805] [81a2b8c6] reqsk_timer_handler+0x156/0x260 [ 6620.282805] [81a2b770] ? inet_csk_reqsk_queue_drop+0x1f0/0x1f0 [ 6620.282805] [8110f3c7] call_timer_fn.isra.27+0x17/0x80 [ 6620.282805] [81a2b770] ? inet_csk_reqsk_queue_drop+0x1f0/0x1f0 [ 6620.282805] [8110f55d] run_timer_softirq+0x12d/0x200 [ 6620.282805] [810ca6c3] __do_softirq+0x103/0x210 [ 6620.282805] [810ca9cb] irq_exit+0x4b/0xa0 [ 6620.282805] [814f05d4] xen_evtchn_do_upcall+0x34/0x50 [ 6620.282805] [81af932e] xen_do_hypervisor_callback+0x1e/0x40 [ 6620.282805] EOI [ 6620.282805] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [ 6620.282805] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [ 6620.282805] [81008d60] ? xen_safe_halt+0x10/0x20 [ 6620.282805] [810188d3] ? default_idle+0x13/0x20 [ 6620.282805] [81018e1a] ? arch_cpu_idle+0xa/0x10 [ 6620.282805] [810f8e7e] ? default_idle_call+0x2e/0x50 [ 6620.282805] [810f9112] ? cpu_startup_entry+0x272/0x2e0 [ 6620.282805] [81ae7967] ? rest_init+0x77/0x80 [ 6620.282805] [82312f58] ? start_kernel+0x43b/0x448 [ 6620.282805] [823124ef] ? x86_64_start_reservations+0x2a/0x2c [ 6620.282805] [82316008] ? xen_start_kernel+0x550/0x55c [ 6620.282805] Code: cc 51 41 53 b8 10 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 11 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
On 2015-08-15 00:09, Sander Eikelenboom wrote: On 2015-08-13 00:41, Eric Dumazet wrote: On Wed, 2015-08-12 at 23:46 +0200, Sander Eikelenboom wrote: Thanks for the reminder, but luckily i was aware of that, seen enough of your replies asking for patches to be resubmitted against the other tree ;) Kernel with patch is currently running so fingers crossed. Thanks for testing. I am definitely interested knowing your results. Hmm it seems now commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af is breaking things (have to test if a revert helps) i get this in some guests: Should have done that before, because it wasn't in yet .. and likely to fix the issue, also pulled and compiling now. -- Sander NMI watchdog: BUG: soft lockup - CPU#0 stuck for 506s! [swapper/0:0] [ 6620.282805] Modules linked in: [ 6620.282805] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc6-20150814-linus-doflr-apicrevert+ #1 [ 6620.282805] task: 8221a580 ti: 8220 task.ti: 8220 [ 6620.282805] RIP: e030:[8100122a] [8100122a] xen_hypercall_xen_version+0xa/0x20 [ 6620.282805] RSP: e02b:88000fc03d48 EFLAGS: 0246 [ 6620.282805] RAX: 00040006 RBX: 0200 RCX: 8100122a [ 6620.282805] RDX: 0001 RSI: deadbeef RDI: deadbeef [ 6620.282805] RBP: 88000fc03d60 R08: 88000fc03ee0 R09: 00ee [ 6620.282805] R10: 8220a0c0 R11: 0246 R12: [ 6620.282805] R13: 0001 R14: 880003b53054 R15: 0005 [ 6620.282805] FS: 7fec747ad800() GS:88000fc0() knlGS: [ 6620.282805] CS: e033 DS: ES: CR0: 8005003b [ 6620.282805] CR2: 7ffcb7a7a6d8 CR3: 03164000 CR4: 0660 [ 6620.282805] Stack: [ 6620.282805] 0068 0007 81008dbd 88000fc03dd8 [ 6620.282805] 81009592 0068 8220a0c0 00ee [ 6620.282805] 88000fc03ee0 0200 0200 0001 [ 6620.282805] Call Trace: [ 6620.282805] IRQ [ 6620.282805] [81008dbd] ? xen_force_evtchn_callback+0xd/0x10 [ 6620.282805] [81009592] check_events+0x12/0x20 [ 6620.282805] [8100957f] ? xen_restore_fl_direct_reloc+0x4/0x4 [ 6620.282805] [81af79a5] ? _raw_spin_unlock_irqrestore+0x25/0x30 [ 6620.282805] [8110ed43] try_to_del_timer_sync+0x43/0x60 [ 6620.282805] [8110eda7] del_timer_sync+0x47/0x60 [ 6620.282805] [81a2b698] inet_csk_reqsk_queue_drop+0x118/0x1f0 [ 6620.282805] [81a2b8c6] reqsk_timer_handler+0x156/0x260 [ 6620.282805] [81a2b770] ? inet_csk_reqsk_queue_drop+0x1f0/0x1f0 [ 6620.282805] [8110f3c7] call_timer_fn.isra.27+0x17/0x80 [ 6620.282805] [81a2b770] ? inet_csk_reqsk_queue_drop+0x1f0/0x1f0 [ 6620.282805] [8110f55d] run_timer_softirq+0x12d/0x200 [ 6620.282805] [810ca6c3] __do_softirq+0x103/0x210 [ 6620.282805] [810ca9cb] irq_exit+0x4b/0xa0 [ 6620.282805] [814f05d4] xen_evtchn_do_upcall+0x34/0x50 [ 6620.282805] [81af932e] xen_do_hypervisor_callback+0x1e/0x40 [ 6620.282805] EOI [ 6620.282805] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [ 6620.282805] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [ 6620.282805] [81008d60] ? xen_safe_halt+0x10/0x20 [ 6620.282805] [810188d3] ? default_idle+0x13/0x20 [ 6620.282805] [81018e1a] ? arch_cpu_idle+0xa/0x10 [ 6620.282805] [810f8e7e] ? default_idle_call+0x2e/0x50 [ 6620.282805] [810f9112] ? cpu_startup_entry+0x272/0x2e0 [ 6620.282805] [81ae7967] ? rest_init+0x77/0x80 [ 6620.282805] [82312f58] ? start_kernel+0x43b/0x448 [ 6620.282805] [823124ef] ? x86_64_start_reservations+0x2a/0x2c [ 6620.282805] [82316008] ? xen_start_kernel+0x550/0x55c [ 6620.282805] Code: cc 51 41 53 b8 10 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 11 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
On Sat, 2015-08-15 at 00:09 +0200, Sander Eikelenboom wrote: On 2015-08-13 00:41, Eric Dumazet wrote: On Wed, 2015-08-12 at 23:46 +0200, Sander Eikelenboom wrote: Thanks for the reminder, but luckily i was aware of that, seen enough of your replies asking for patches to be resubmitted against the other tree ;) Kernel with patch is currently running so fingers crossed. Thanks for testing. I am definitely interested knowing your results. Hmm it seems now commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af is breaking things (have to test if a revert helps) i get this in some guests: Yes, this was fixed by : http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=83fccfc3940c4a2db90fd7e7079f5b465cd8c6af ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] xen: arm: Set all bits in mfn_to_xen_entry()
Ensure that every bit has a specific value. Reported-by: Julien Grall julien.gr...@citrix.com Signed-off-by: Chris Brand chris.br...@broadcom.com --- xen/include/asm-arm/page.h | 5 + 1 file changed, 5 insertions(+) diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h index 01628f3e96cb..7a56b2cb463a 100644 --- a/xen/include/asm-arm/page.h +++ b/xen/include/asm-arm/page.h @@ -202,9 +202,14 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn, unsigned attr) .ai = attr, .ns = 1, /* Hyp mode is in the non-secure world */ .user = 1,/* See below */ +.ro = 0, /* Assume read-write */ .af = 1, /* No need for access tracking */ .ng = 1, /* Makes TLB flushes easier */ +.sbz = 0, +.contig = 0, /* Assume non-contiguous */ +.pxn = 0, .xn = 1, /* No need to execute outside .text */ +.avail = 0, }};; /* Setting the User bit is strange, but the ATS1H[RW] instructions * don't seem to work otherwise, and since we never run on Xen -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 03/10] xen/pt: Check if reg-init function sets the 'data' past the reg-size
On Fri, Jul 17, 2015 at 05:03:44PM +0100, Stefano Stabellini wrote:
On Thu, 2 Jul 2015, Konrad Rzeszutek Wilk wrote:
It should never happen, but in case it does (an developer adds
a new register and the 'init_val' expands past the register
size) we want to report. The code will only write up to
reg-size so there is no runtime danger of the register spilling
across other ones - however to catch this sort of thing
we still return an error.
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
hw/xen/xen_pt_config_init.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 3938afd..09309ba 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -1904,9 +1904,15 @@ static int
xen_pt_config_reg_init(XenPCIPassthroughState *s,
} else
val = data;
+if (val ~size_mask) {
+XEN_PT_ERR(s-dev,Offset 0x%04x:0x%04x expands past register
size(%d)!\n,
+ offset, val, reg-size);
+g_free(reg_entry);
+return -ENXIO;
+}
If we worry about changes to init_val, wouldn't it be better to add
QEMU_BUILD_BUG_ON(data ~size_mask)?
I couldnt' figure out how to make that work nicely.
The QEMU_BUILD_BUG_ON look to be build time - not run-time.
Which means that doing:
for (i = 0; i grp_entries; i++)
{
entries = grp_entries[i]...
for (j = 0; j entries; j++)
QEMU_BUILD_BUG_ON(entries[j].init_val ~size_mask)
}
is not something I can image the compiler working with?
/* This could be just pci_set_long as we don't modify the bits
- * past reg-size, but in case this routine is run in parallel
- * we do not want to over-write other registers. */
+ * past reg-size, but in case this routine is run in parallel or
the
+ * init value is larger, we do not want to over-write registers. */
switch (reg-size) {
case 1: pci_set_byte(s-dev.config + offset, (uint8_t)val); break;
case 2: pci_set_word(s-dev.config + offset, (uint16_t)val); break;
--
2.1.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Buggy IOMMU support in Coreboot on Chromebook Pixel 2 i7-5600U
On 2015-08-14 01:41, Andrew Cooper wrote: On 14/08/15 08:13, fowlsl...@riseup.net wrote: On the VT-d troubleshooting page, I was informed to shoot you all a message if Xen had to deactivate my VT-d due to errors in my BIOS (in this case Coreboot). I am running John Lewis' Coreboot ROM for the Chromebook Pixel 2 (samus) w/ the i7-5600U processor and Xen 4.4.2 on Qubes. I downloaded and cracked open (for lack of better words) John Lewis's Coreboot image (which is a modified version of the one in the Google repos) and found that src/arch/x86/acpi.c had the same section added by the http://review.coreboot.org/#/c/1654/ commit written by Patrick Georgi a few years back that is supposed to provide ACPI DMAR tables. The problem might just be the code is out of date for modern processors or maybe it has just not been tested against many CPUs. It does appear that there has been changes to this acpi.c file in the Coreboot master branch, which makes me wonder if building against that would fix my problems. Realistically though, I have barely any experience or knowledge with Coreboot hacking and I'm assuming there is a web of dependencies that I couldn't figure out without possibly months of research, trial, and error. Anyway, just wanted to send in this report as maybe you don't get too many involving Coreboot and maybe you might find it interesting or in the minute chance you might be able to help me out. Anyway, here's the output of `xl dmesg`: Please reboot and use iommu=verbose,debug on the Xen command line, which will offer more information. ~Andrew I was already passing iommu=verbose, but not debug as well. Here is the new log Xen 4.4.2-6.fc20 (XEN) Xen version 4.4.2 (user@) (gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)) debug=n Thu Jul 23 20:12:15 UTC 2015 (XEN) Latest ChangeSet: (XEN) Bootloader: GRUB 2.00 (XEN) Command line: placeholder console=none dom0_mem=min:1024M iommu=verbose,debug (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) Disc information: (XEN) Found 2 MBR signatures (XEN) Found 2 EDD information structures (XEN) Xen-e820 RAM map: (XEN) - 0009fc00 (usable) (XEN) 0009fc00 - 000a (reserved) (XEN) 000f - 0010 (reserved) (XEN) 0010 - 7ce27000 (usable) (XEN) 7ce27000 - 8000 (reserved) (XEN) f000 - f400 (reserved) (XEN) fed1 - fed1a000 (reserved) (XEN) fed4 - fed45000 (reserved) (XEN) fed8 - fed85000 (reserved) (XEN) 0001 - 00047f00 (usable) (XEN) ACPI: RSDP 000F2760, 0024 (r2 CORE ) (XEN) ACPI: XSDT 7CF440E0, 004C (r1 CORE COREBOOT0 CORE 0) (XEN) ACPI: FACP 7CF48970, 00F4 (r5 CORE COREBOOT0 CORE 1) (XEN) ACPI: DSDT 7CF44250, 4720 (r2 COREv4 COREBOOT 20110725 INTL 20130117) (XEN) ACPI: FACS 7CF44210, 0040 (XEN) ACPI: HPET 7CF48A70, 0038 (r1 CORE COREBOOT0 CORE 0) (XEN) ACPI: APIC 7CF48AB0, 006C (r1 CORE COREBOOT0 CORE 0) (XEN) ACPI: MCFG 7CF48B20, 003C (r1 CORE COREBOOT0 CORE 0) (XEN) ACPI: SSDT 7CF49BC0, 0FF8 (r2 CORE COREBOOT 2A CORE 2A) (XEN) System RAM: 16317MB (16709400kB) (XEN) Domain heap initialised (XEN) Processor #0 7:13 APIC version 21 (XEN) Processor #1 7:13 APIC version 21 (XEN) Processor #3 7:13 APIC version 21 (XEN) Processor #2 7:13 APIC version 21 (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-39 (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) Not enabling x2APIC: depends on iommu_supports_eim. (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2394.503 MHz processor. (XEN) Initing memory sharing. (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) I/O virtualisation disabled (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) ENABLING IO-APIC IRQs (XEN) - Using old ACK method (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 16 KiB. (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Extended Page Tables (EPT) (XEN) - Virtual-Processor Identifiers (VPID) (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) - Unrestricted Guest (XEN) HVM: ASIDs enabled. (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB (XEN) Brought up 4 CPUs (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 - 0x204d000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 00046800-00047000 (4056562 pages to be allocated) (XEN) Init. ramdisk: 00047cb6a000-00047f00 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: 8100-8204d000 (XEN) Init. ramdisk:
[Xen-devel] [linux-3.4 test] 60677: regressions - FAIL
flight 60677 linux-3.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/60677/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 30511 Tests which are failing intermittently (not blocking): test-amd64-i386-rumpuserxen-i386 2 hosts-allocate broken in 60224 pass in 60677 test-amd64-amd64-rumpuserxen-amd64 2 hosts-allocate broken in 60224 pass in 60677 test-amd64-i386-xl-qemuu-win7-amd64 2 hosts-allocate broken in 60224 pass in 60677 test-amd64-i386-xl-qemut-win7-amd64 2 hosts-allocate broken in 60224 pass in 60677 test-amd64-amd64-xl-sedf-pin 6 xen-boot fail in 58831 pass in 58798 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail in 58831 pass in 60677 test-amd64-i386-pair 10 xen-boot/dst_host fail pass in 58831 test-amd64-i386-pair 9 xen-boot/src_host fail pass in 58831 test-amd64-amd64-xl 6 xen-bootfail pass in 59576 test-amd64-amd64-pair10 xen-boot/dst_host fail pass in 59961 test-amd64-amd64-libvirt 6 xen-bootfail pass in 60064 test-amd64-amd64-pair 9 xen-boot/src_host fail pass in 60224 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-libvirt-qcow2 2 hosts-allocate broken in 60224 baseline untested test-amd64-amd64-libvirt-raw 2 hosts-allocate broken in 60224 baseline untested test-amd64-amd64-libvirt-vhd 2 hosts-allocate broken in 60224 baseline untested test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-i386-libvirt-xsm 6 xen-bootfail baseline untested test-amd64-amd64-xl-xsm 6 xen-bootfail baseline untested test-amd64-amd64-xl-multivcpu 6 xen-boot fail baseline untested test-amd64-i386-xl-xsm6 xen-bootfail baseline untested test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-amd64-xl-credit2 6 xen-bootfail baseline untested test-amd64-amd64-libvirt-qcow2 6 xen-boot fail baseline untested test-amd64-amd64-xl-rtds 6 xen-bootfail baseline untested test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 fail baseline untested test-amd64-i386-libvirt-raw 10 guest-start fail baseline untested test-amd64-amd64-xl-sedf 6 xen-boot fail in 58831 like 30406 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 12 guest-localmigrate fail in 59576 baseline untested test-amd64-amd64-libvirt-xsm 6 xen-boot fail in 59576 baseline untested test-amd64-amd64-libvirt 11 guest-start fail in 59576 like 30511 test-amd64-i386-libvirt 11 guest-start fail in 59576 like 30511 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 11 guest-saverestore fail in 59961 baseline untested test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail in 59961 like 30394 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 60064 blocked in 30511 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 30511 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 30511 test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-bootfail like 53709-bisect test-amd64-i386-xl6 xen-bootfail like 53725-bisect test-amd64-i386-freebsd10-amd64 6 xen-boot fail like 58780-bisect test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail like 58786-bisect test-amd64-i386-qemut-rhel6hvm-intel 6 xen-bootfail like 58788-bisect test-amd64-i386-rumpuserxen-i386 6 xen-bootfail like 58799-bisect test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-bootfail like 58801-bisect test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail like 58803-bisect test-amd64-amd64-xl-qemut-winxpsp3 6 xen-boot fail like 58804-bisect test-amd64-i386-freebsd10-i386 6 xen-boot fail like 58805-bisect test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail like 58806-bisect test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail like 58807-bisect test-amd64-i386-xl-qemut-winxpsp3 6 xen-boot fail like 58808-bisect test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-bootfail like 58809-bisect test-amd64-amd64-rumpuserxen-amd64 6 xen-boot fail like 58810-bisect test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-bootfail like 58811-bisect test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail
[Xen-devel] Could Xen hyperviosr be able to invoke Linux systemcalls?
Hi all, That might be a dumb question but I just not confident with it. I'm not familiar with Xen's memory management part. Currently I want to add some support (it should cope more with machine memory) to the hyperviosr to assist the management of the above VMs. Now the situation is there're some codes in the kernel which are supposed to be useful. but can Xen call Linux system calls or other kernel functions? I'm not pretty sure about this as in my understanding xen hyperviosr lies under the kernel, so it can't invoke a systemcall from the kernel (or let's say dom0's kernel) . Then if I want to use those codes, I suppose I have to implement them in the hyperviosr by myself, right? And does anyone know which one of xen's wiki pages explain the management APIs of xen's memory? Thank you all. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Buggy IOMMU support in Coreboot on Chromebook Pixel 2 i7-5600U
On 15/08/15 06:14, fowlsl...@riseup.net wrote: On 2015-08-14 01:41, Andrew Cooper wrote: On 14/08/15 08:13, fowlsl...@riseup.net wrote: On the VT-d troubleshooting page, I was informed to shoot you all a message if Xen had to deactivate my VT-d due to errors in my BIOS (in this case Coreboot). I am running John Lewis' Coreboot ROM for the Chromebook Pixel 2 (samus) w/ the i7-5600U processor and Xen 4.4.2 on Qubes. I downloaded and cracked open (for lack of better words) John Lewis's Coreboot image (which is a modified version of the one in the Google repos) and found that src/arch/x86/acpi.c had the same section added by the http://review.coreboot.org/#/c/1654/ commit written by Patrick Georgi a few years back that is supposed to provide ACPI DMAR tables. The problem might just be the code is out of date for modern processors or maybe it has just not been tested against many CPUs. It does appear that there has been changes to this acpi.c file in the Coreboot master branch, which makes me wonder if building against that would fix my problems. Realistically though, I have barely any experience or knowledge with Coreboot hacking and I'm assuming there is a web of dependencies that I couldn't figure out without possibly months of research, trial, and error. Anyway, just wanted to send in this report as maybe you don't get too many involving Coreboot and maybe you might find it interesting or in the minute chance you might be able to help me out. Anyway, here's the output of `xl dmesg`: Please reboot and use iommu=verbose,debug on the Xen command line, which will offer more information. ~Andrew I was already passing iommu=verbose, but not debug as well. Here is the new log Not the one you posted. Line 4 prints the full command line as passed to Xen. Anyhow, ... Xen 4.4.2-6.fc20 (XEN) Xen version 4.4.2 (user@) (gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)) debug=n Thu Jul 23 20:12:15 UTC 2015 (XEN) Latest ChangeSet: (XEN) Bootloader: GRUB 2.00 (XEN) Command line: placeholder console=none dom0_mem=min:1024M iommu=verbose,debug (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) Disc information: (XEN) Found 2 MBR signatures (XEN) Found 2 EDD information structures (XEN) Xen-e820 RAM map: (XEN) - 0009fc00 (usable) (XEN) 0009fc00 - 000a (reserved) (XEN) 000f - 0010 (reserved) (XEN) 0010 - 7ce27000 (usable) (XEN) 7ce27000 - 8000 (reserved) (XEN) f000 - f400 (reserved) (XEN) fed1 - fed1a000 (reserved) (XEN) fed4 - fed45000 (reserved) (XEN) fed8 - fed85000 (reserved) (XEN) 0001 - 00047f00 (usable) (XEN) ACPI: RSDP 000F2760, 0024 (r2 CORE ) (XEN) ACPI: XSDT 7CF440E0, 004C (r1 CORE COREBOOT0 CORE0) (XEN) ACPI: FACP 7CF48970, 00F4 (r5 CORE COREBOOT0 CORE1) (XEN) ACPI: DSDT 7CF44250, 4720 (r2 COREv4 COREBOOT 20110725 INTL 20130117) (XEN) ACPI: FACS 7CF44210, 0040 (XEN) ACPI: HPET 7CF48A70, 0038 (r1 CORE COREBOOT0 CORE0) (XEN) ACPI: APIC 7CF48AB0, 006C (r1 CORE COREBOOT0 CORE0) (XEN) ACPI: MCFG 7CF48B20, 003C (r1 CORE COREBOOT0 CORE0) (XEN) ACPI: SSDT 7CF49BC0, 0FF8 (r2 CORE COREBOOT 2A CORE 2A) (XEN) System RAM: 16317MB (16709400kB) ... there is no DMAR table, which means that coreboot has not told Xen that an IOMMU exists on the system. ~Andrew snip ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 60679: all pass - PUSHED
flight 60679 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60679/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 0cd1ecea673160417e30e46009a54d361a131235
baseline version:
ovmf bc0f20c11a82e484cd160d5c4ddf1644653ffe2c
Last test of basis60661 2015-08-11 15:38:43 Z3 days
Testing same since60679 2015-08-12 20:10:09 Z2 days1 attempts
People who touched revisions under test:
Ard Biesheuvel ard.biesheu...@linaro.org
Qiu Shumin shumin@intel.com
Zhang Lubo lubo.zh...@intel.com
jobs:
build-amd64-xsm pass
build-i386-xsm pass
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-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=0cd1ecea673160417e30e46009a54d361a131235
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
0cd1ecea673160417e30e46009a54d361a131235
+ branch=ovmf
+ revision=0cd1ecea673160417e30e46009a54d361a131235
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case $branch in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{OsstestUpstream} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/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.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/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://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ :
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ :
Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 3
On Fri, Aug 14, 2015 at 10:59:19PM +0800, Shannon Zhao wrote:
This document is going to explain the design details of Xen booting with
ACPI on ARM. Maybe parts of it may not be appropriate. Any comments are
welcome.
Changes v2-v3:
* remove the two HVM_PARAMs for grant table and let linux kernel use
xlated_setup_gnttab_pages() to setup grant table.
* don't modify GTDT table
* add definition of event-channel interrupt flag
* state that route all Xen unused interrupt to Dom0
* state that reusing existing PCI bus_notifier for PCI devices MMIO mapping
To Xen itself booting with ACPI, this is similar to Linux kernel except
that Xen doesn't parse DSDT table. So I'll skip this part and focus on
how Xen prepares ACPI tables for Dom0 and how Xen passes them to Dom0.
1. Copy and change some EFI and ACPI tables
---
a) Copy EFI_SYSTEM_TABLE and change the value of FirmwareVendor,
VendorGuid, VendorTable, ConfigurationTable. These changes are not very
special and it just assign values to these members.
b) Create EFI_MEMORY_DESCRIPTOR table. This will add memory start and
size information of Dom0. And Dom0 will get the memory information
through this EFI table.
c) Copy FADT table. Change the value of arm_boot_flags to enable PSCI
and HVC. Let the hypervisor_id be XenVMM in order to tell Dom0 that it
runs on Xen hypervisor, then Dom0 could through HVM_PARAM to get some
informations for booting necessity, such as event-channel interrupt.
Change header revison, length and checksum as well.
d) Copy MADT table. According to the value of dom0_max_vcpus to change
the number GICC entries.
e) Create STAO table. This table is a new added one that's used to
define a list of ACPI namespace names that are to be ignored by the OSPM
in Dom0. Currently we use it to tell OSPM should ignore UART defined in
SPCR table.
Would it make sense to include this URL
http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf
f) Copy XSDT table. Add a new table entry for STAO and change other
table's entries.
g) Change the value of xsdt_physical_address in RSDP table.
h) The rest of tables are not copied or changed. They are reused
including DSDT, SPCR, GTDT, etc.
All these tables will be copied to Dom0 memory except that the reused
tables(DSDT, SPCR, GTDT, etc) will be mapped to Dom0.
2. Create minimal DT to pass required information to Dom0
--
The minimal DT mainly passes Dom0 bootargs, address and size of initrd
(if available), address and size of uefi system table, address and size
of uefi memory table, uefi-mmap-desc-size and uefi-mmap-desc-ver.
An example of the minimal DT:
/ {
#address-cells = 2;
#size-cells = 1;
chosen {
bootargs = kernel=Image console=hvc0 earlycon=pl011,0x1c09
root=/dev/vda2 rw rootfstype=ext4 init=/bin/sh acpi=force;
linux,initrd-start = 0x;
linux,initrd-end = 0x;
linux,uefi-system-table = 0x;
linux,uefi-mmap-start = 0x;
linux,uefi-mmap-size = 0x;
linux,uefi-mmap-desc-size = 0x;
linux,uefi-mmap-desc-ver = 0x;
};
};
For details loook at
https://github.com/torvalds/linux/blob/master/Documentation/arm/uefi.txt
3. Dom0 gets grant table and event channel irq information
---
Make Linux call xlated_setup_gnttab_pages() to setup grant table. So it
doesn't need Xen pass grant table start and size information to Dom0.
To event channel interrupt, reuse HVM_PARAM_CALLBACK_IRQ and add a new
delivery type to get it.
val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI (ARM and ARM64
only)
The definition of flag reusing the definition of xenv table. Bit 0
stands interrupt mode and bit 1 stands interrupt polarity.
As said above, we assign the hypervisor_id be XenVMM to tell Dom0 that
it runs on Xen hypervisor. Then Dom0 could get it through hypercall
HVMOP_get_param.
4. Map MMIO regions
---
Register a bus_notifier for platform and amba bus in Linux. Add a new
XENMAPSPACE XENMAPSPACE_dev_mmio. Within the register, check if the
device is newly added, then call hypercall XENMEM_add_to_physmap to map
the mmio regions.
For PCI bus device, it could reuse the existing PCI bus_notifier like
X86.
5. Route device interrupts to Dom0
--
Route all the SPI interrupts to Dom0 before Dom0 booting, except the
interrupts used by Xen. For uart, it could get the interrupt from SPCR
table and exclude it. For SMMU, it could get the interrupts from IORT
table and exclude them as well.
Thanks,
--
Shannon
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/x86: Clean up vm_event-related code in asm-x86/domain.h
On 14.08.15 at 12:30, rcojoc...@bitdefender.com wrote:
On 08/14/2015 01:21 PM, Jan Beulich wrote:
On 14.08.15 at 11:54, rcojoc...@bitdefender.com wrote:
@@ -460,6 +459,18 @@ typedef enum __packed {
SMAP_CHECK_DISABLED,/* disable the check */
} smap_check_policy_t;
+/*
+ * Should we emulate the next matching instruction on VCPU resume
+ * after a vm_event?
+ */
+struct vm_event {
+uint32_t emulate_flags;
+unsigned long gpa;
+unsigned long eip;
+struct vm_event_emul_read_data emul_read_data;
+struct monitor_write_data write_data;
+};
... this would better go into asm-x86/vm_event.h (despite it meaning
that the file will then be included by basically everything).
Ack.
And actually (having looked another time) I don't think this implies
including asm/vm_event.h from asm-x86/domain.h.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-4.3-testing test] 60676: regressions - FAIL
flight 60676 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/60676/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-raw9 debian-di-install fail REGR. vs. 60159 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-libvirt 17 guest-start.2 fail REGR. vs. 60159 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail REGR. vs. 60159 test-amd64-i386-libvirt 11 guest-start fail like 60159 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 60159 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-amd64-xl-raw 9 debian-di-installfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 9 debian-di-installfail never pass test-amd64-amd64-libvirt-qcow2 14 guest-saverestore.2 fail never pass test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qcow2 9 debian-di-installfail never pass test-amd64-i386-libvirt-vhd 9 debian-di-installfail never pass test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 17 guest-start/debian.repeatfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass version targeted for testing: qemuu20c1b1812de98ed789d55e22a43a4700fb765596 baseline version: qemuu25c99f89476080f4e3ba221437916b5a38208e03 Last test of basis60159 2015-07-30 18:44:41 Z 14 days Testing same since60676 2015-08-12 13:39:17 Z1 days1 attempts People who touched revisions under test: James Harper james.har...@ejbdigital.com.au James Harper ja...@ejbdigital.com.au Stefan Hajnoczi stefa...@redhat.com Stefano Stabellini stefano.stabell...@eu.citrix.com 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-i386-qemuu-rhel6hvm-amd 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 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-credit2 pass test-amd64-i386-freebsd10-i386 pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt fail test-amd64-i386-libvirt fail test-amd64-amd64-xl-multivcpupass test-amd64-amd64-pairpass test-amd64-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-amd64-pvgrubpass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 fail test-amd64-i386-libvirt-qcow2fail test-amd64-amd64-xl-qcow2pass test-amd64-i386-xl-qcow2 pass test-amd64-amd64-libvirt-raw fail test-amd64-i386-libvirt-raw fail test-amd64-amd64-xl-raw fail test-amd64-i386-xl-raw fail test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
Re: [Xen-devel] [PATCH v2 1/2] ACPI/table: Always count matched and successfully parsed entries
Hi Shannon, On 14/08/15 04:36, Shannon Zhao wrote: From: Tomasz Nowicki tomasz.nowi...@linaro.org Ported from Linux commit 4ceacd02f5a1795c5c697e0345ee10beef675290. acpi_parse_entries() allows to traverse all available table entries (aka subtables) by passing max_entries parameter equal to 0, but since its count variable is only incremented if max_entries is not 0, the function always returns 0 for max_entries equal to 0. It would be more useful if it returned the number of entries matched instead, so make it increment count in that case too. Acked-by: Grant Likely grant.lik...@linaro.org Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org Signed-off-by: Hanjun Guo hanjun@linaro.org Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com Signed-off-by: Shannon Zhao shannon.z...@linaro.org You may want to add an indentation to show this is the commit message from Linux and not Xen. One of the reason behind that it's Grant acked the patch for Linux and not Xen. The patch is nearly the same this time (only the lines change), but it may happen that we need to fix a bit. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [distros-debian-sid test] 37834: regressions - FAIL
flight 37834 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/37834/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-amd64-sid-netboot-pygrub 9 debian-di-install fail REGR. vs. 37816 test-amd64-i386-i386-sid-netboot-pvgrub 9 debian-di-install fail REGR. vs. 37816 test-amd64-amd64-i386-sid-netboot-pygrub 9 debian-di-install fail REGR. vs. 37816 test-amd64-amd64-amd64-sid-netboot-pvgrub 9 debian-di-install fail REGR. vs. 37816 Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-sid-netboot-pygrub 9 debian-di-install fail never pass baseline version: flight 37816 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-sid-netboot-pvgrubfail test-amd64-i386-i386-sid-netboot-pvgrub fail test-amd64-i386-amd64-sid-netboot-pygrub fail test-armhf-armhf-armhf-sid-netboot-pygrubfail test-amd64-amd64-i386-sid-netboot-pygrub fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 1/2] Differentiate IO/mem resources tracked by ioreq server
Currently in ioreq server, guest write-protected ram pages are
tracked in the same rangeset with device mmio resources. Yet
unlike device mmio, which can be in big chunks, the guest write-
protected pages may be discrete ranges with 4K bytes each.
This patch uses a seperate rangeset for the guest ram pages.
And a new ioreq type, IOREQ_TYPE_WP_MEM, is defined.
Note: Previously, a new hypercall or subop was suggested to map
write-protected pages into ioreq server. However, it turned out
handler of this new hypercall would be almost the same with the
existing pair - HVMOP_[un]map_io_range_to_ioreq_server, and there's
already a type parameter in this hypercall. So no new hypercall
defined, only a new type is introduced.
Signed-off-by: Yu Zhang yu.c.zh...@linux.intel.com
---
tools/libxc/include/xenctrl.h| 31 ++
tools/libxc/xc_domain.c | 55
xen/arch/x86/hvm/hvm.c | 25 +-
xen/include/asm-x86/hvm/domain.h | 4 +--
xen/include/public/hvm/hvm_op.h | 1 +
xen/include/public/hvm/ioreq.h | 1 +
6 files changed, 114 insertions(+), 3 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index de3c0ad..3c276b7 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2010,6 +2010,37 @@ int xc_hvm_unmap_io_range_from_ioreq_server(xc_interface
*xch,
int is_mmio,
uint64_t start,
uint64_t end);
+/**
+ * This function registers a range of write-protected memory for emulation.
+ *
+ * @parm xch a handle to an open hypervisor interface.
+ * @parm domid the domain id to be serviced
+ * @parm id the IOREQ Server id.
+ * @parm start start of range
+ * @parm end end of range (inclusive).
+ * @return 0 on success, -1 on failure.
+ */
+int xc_hvm_map_mem_range_to_ioreq_server(xc_interface *xch,
+domid_t domid,
+ioservid_t id,
+xen_pfn_t start,
+xen_pfn_t end);
+
+/**
+ * This function deregisters a range of write-protected memory for emulation.
+ *
+ * @parm xch a handle to an open hypervisor interface.
+ * @parm domid the domain id to be serviced
+ * @parm id the IOREQ Server id.
+ * @parm start start of range
+ * @parm end end of range (inclusive).
+ * @return 0 on success, -1 on failure.
+ */
+int xc_hvm_unmap_mem_range_from_ioreq_server(xc_interface *xch,
+domid_t domid,
+ioservid_t id,
+xen_pfn_t start,
+xen_pfn_t end);
/**
* This function registers a PCI device for config space emulation.
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 2ee26fb..9db05b3 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1552,6 +1552,61 @@ int xc_hvm_unmap_io_range_from_ioreq_server(xc_interface
*xch, domid_t domid,
return rc;
}
+int xc_hvm_map_mem_range_to_ioreq_server(xc_interface *xch, domid_t domid,
+ioservid_t id, xen_pfn_t start,
xen_pfn_t end)
+{
+DECLARE_HYPERCALL;
+DECLARE_HYPERCALL_BUFFER(xen_hvm_io_range_t, arg);
+int rc;
+
+arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
+if ( arg == NULL )
+return -1;
+
+hypercall.op = __HYPERVISOR_hvm_op;
+hypercall.arg[0] = HVMOP_map_io_range_to_ioreq_server;
+hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(arg);
+
+arg-domid = domid;
+arg-id = id;
+arg-type = HVMOP_IO_RANGE_WP_MEM;
+arg-start = start;
+arg-end = end;
+
+rc = do_xen_hypercall(xch, hypercall);
+
+xc_hypercall_buffer_free(xch, arg);
+return rc;
+}
+
+int xc_hvm_unmap_mem_range_from_ioreq_server(xc_interface *xch, domid_t domid,
+ioservid_t id, xen_pfn_t start,
xen_pfn_t end)
+{
+DECLARE_HYPERCALL;
+DECLARE_HYPERCALL_BUFFER(xen_hvm_io_range_t, arg);
+int rc;
+
+arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
+if ( arg == NULL )
+return -1;
+
+hypercall.op = __HYPERVISOR_hvm_op;
+hypercall.arg[0] = HVMOP_unmap_io_range_from_ioreq_server;
+hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(arg);
+
+arg-domid = domid;
+arg-id = id;
+arg-type = HVMOP_IO_RANGE_WP_MEM;
+arg-start = start;
+arg-end = end;
+
+rc = do_xen_hypercall(xch, hypercall);
+
+xc_hypercall_buffer_free(xch, arg);
+return rc;
+
+}
+
int xc_hvm_map_pcidev_to_ioreq_server(xc_interface *xch, domid_t domid,
ioservid_t id, uint16_t segment,
uint8_t bus, uint8_t device,
diff
[Xen-devel] [PATCH v5 2/2] Refactor rangeset structure for better performance.
This patch refactors struct rangeset to base it on the red-black
tree structure, instead of on the current doubly linked list. By
now, ioreq leverages rangeset to keep track of the IO/memory
resources to be emulated. Yet when number of ranges inside one
ioreq server is very high, traversing a doubly linked list could
be time consuming. With this patch, the time complexity for
searching a rangeset can be improved from O(n) to O(log(n)).
Interfaces of rangeset still remain the same, and no new APIs
introduced.
Signed-off-by: Yu Zhang yu.c.zh...@linux.intel.com
---
xen/common/rangeset.c | 82 +--
1 file changed, 60 insertions(+), 22 deletions(-)
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index 6c6293c..cde0d06 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -10,11 +10,12 @@
#include xen/sched.h
#include xen/errno.h
#include xen/rangeset.h
+#include xen/rbtree.h
#include xsm/xsm.h
/* An inclusive range [s,e] and pointer to next range in ascending order. */
struct range {
-struct list_head list;
+struct rb_node node;
unsigned long s, e;
};
@@ -24,7 +25,7 @@ struct rangeset {
struct domain *domain;
/* Ordered list of ranges contained in this set, and protecting lock. */
-struct list_head range_list;
+struct rb_root range_tree;
/* Number of ranges that can be allocated */
long nr_ranges;
@@ -45,41 +46,78 @@ struct rangeset {
static struct range *find_range(
struct rangeset *r, unsigned long s)
{
-struct range *x = NULL, *y;
+struct rb_node *node;
+struct range *x;
+struct range *prev = NULL;
-list_for_each_entry ( y, r-range_list, list )
+node = r-range_tree.rb_node;
+while ( node )
{
-if ( y-s s )
-break;
-x = y;
+x = container_of(node, struct range, node);
+if ( (s = x-s) (s = x-e) )
+return x;
+if ( s x-s )
+node = node-rb_left;
+else
+{
+prev = x;
+node = node-rb_right;
+}
}
-return x;
+return prev;
}
/* Return the lowest range in the set r, or NULL if r is empty. */
static struct range *first_range(
struct rangeset *r)
{
-if ( list_empty(r-range_list) )
-return NULL;
-return list_entry(r-range_list.next, struct range, list);
+struct rb_node *node;
+
+node = rb_first(r-range_tree);
+if ( node != NULL )
+return container_of(node, struct range, node);
+
+return NULL;
}
/* Return range following x in ascending order, or NULL if x is the highest. */
static struct range *next_range(
struct rangeset *r, struct range *x)
{
-if ( x-list.next == r-range_list )
-return NULL;
-return list_entry(x-list.next, struct range, list);
+struct rb_node *node;
+
+node = rb_next(x-node);
+if ( node )
+return container_of(node, struct range, node);
+
+return NULL;
}
/* Insert range y after range x in r. Insert as first range if x is NULL. */
static void insert_range(
struct rangeset *r, struct range *x, struct range *y)
{
-list_add(y-list, (x != NULL) ? x-list : r-range_list);
+struct rb_node **node;
+struct rb_node *parent = NULL;
+
+if ( x == NULL )
+node = r-range_tree.rb_node;
+else
+{
+node = x-node.rb_right;
+parent = x-node;
+}
+
+while ( *node )
+{
+parent = *node;
+node = parent-rb_left;
+}
+
+/* Add new node and rebalance the red-black tree. */
+rb_link_node(y-node, parent, node);
+rb_insert_color(y-node, r-range_tree);
}
/* Remove a range from its list and free it. */
@@ -88,7 +126,7 @@ static void destroy_range(
{
r-nr_ranges++;
-list_del(x-list);
+rb_erase(x-node, r-range_tree);
xfree(x);
}
@@ -319,7 +357,7 @@ bool_t rangeset_contains_singleton(
bool_t rangeset_is_empty(
const struct rangeset *r)
{
-return ((r == NULL) || list_empty(r-range_list));
+return ((r == NULL) || RB_EMPTY_ROOT(r-range_tree));
}
struct rangeset *rangeset_new(
@@ -332,7 +370,7 @@ struct rangeset *rangeset_new(
return NULL;
rwlock_init(r-lock);
-INIT_LIST_HEAD(r-range_list);
+r-range_tree = RB_ROOT;
r-nr_ranges = -1;
BUG_ON(flags ~RANGESETF_prettyprint_hex);
@@ -410,7 +448,7 @@ void rangeset_domain_destroy(
void rangeset_swap(struct rangeset *a, struct rangeset *b)
{
-LIST_HEAD(tmp);
+struct rb_node* tmp;
if ( a b )
{
@@ -423,9 +461,9 @@ void rangeset_swap(struct rangeset *a, struct rangeset *b)
write_lock(a-lock);
}
-list_splice_init(a-range_list, tmp);
-list_splice_init(b-range_list, a-range_list);
-list_splice(tmp, b-range_list);
+tmp = a-range_tree.rb_node;
+a-range_tree.rb_node = b-range_tree.rb_node;
+b-range_tree.rb_node = tmp;
[Xen-devel] [PATCH v5 0/2] Refactor ioreq server for better performance.
XenGT leverages ioreq server to track and forward the accesses to GPU I/O resources, e.g. the PPGTT(per-process graphic translation tables). Currently, ioreq server uses rangeset to track the BDF/ PIO/MMIO ranges to be emulated. To select an ioreq server, the rangeset is searched to see if the I/O range is recorded. However, traversing the link list inside rangeset could be time consuming when number of ranges is too high. On HSW platform, number of PPGTTs for each vGPU could be several hundred. On BDW, this value could be several thousand. This patch series refactored rangeset to base it on red-back tree, so that the searching would be more efficient. Besides, this patchset also splits the tracking of MMIO and guest ram ranges into different rangesets. And to accommodate more ranges, limitation of the number of ranges in an ioreq server, MAX_NR_IO_RANGES is changed - future patches might be provided to tune this with other approaches. Changes in v5: 1 Use gpfn, instead of gpa to track guest write-protected pages; 2 Remove redundant conditional statement in routine find_range(). Changes in v4: Keep the name HVMOP_IO_RANGE_MEMORY for MMIO resources, and add a new one, HVMOP_IO_RANGE_WP_MEM, for write-protected memory. Changes in v3: 1 Use a seperate rangeset for guest ram pages in ioreq server; 2 Refactor rangeset, instead of introduce a new data structure. Changes in v2: 1 Split the original patch into 2; 2 Take Paul Durrant's comments: a Add a name member in the struct rb_rangeset, and use the 'q' debug key to dump the ranges in ioreq server; b Keep original routine names for hvm ioreq server; c Commit message changes - mention that a future patch to change the maximum ranges inside ioreq server. Yu Zhang (2): Differentiate IO/mem resources tracked by ioreq server Refactor rangeset structure for better performance. tools/libxc/include/xenctrl.h| 31 +++ tools/libxc/xc_domain.c | 55 +++ xen/arch/x86/hvm/hvm.c | 25 +++- xen/common/rangeset.c| 82 +--- xen/include/asm-x86/hvm/domain.h | 4 +- xen/include/public/hvm/hvm_op.h | 1 + xen/include/public/hvm/ioreq.h | 1 + 7 files changed, 174 insertions(+), 25 deletions(-) -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v2 0/5] Multi-queue support for xen-blkfront and xen-blkback
On 14/08/15 09:31, Bob Liu wrote: On 08/13/2015 12:46 AM, Rafal Mielniczuk wrote: On 12/08/15 11:17, Bob Liu wrote: On 08/12/2015 01:32 AM, Jens Axboe wrote: On 08/11/2015 03:45 AM, Rafal Mielniczuk wrote: On 11/08/15 07:08, Bob Liu wrote: On 08/10/2015 11:52 PM, Jens Axboe wrote: On 08/10/2015 05:03 AM, Rafal Mielniczuk wrote: ... Hello, We rerun the tests for sequential reads with the identical settings but with Bob Liu's multiqueue patches reverted from dom0 and guest kernels. The results we obtained were *better* than the results we got with multiqueue patches applied: fio_threads io_depth block_size 1-queue_iops 8-queue_iops *no-mq-patches_iops* 8 32 512 158K 264K 321K 8 321K 157K 260K 328K 8 322K 157K 258K 336K 8 324K 148K 257K 308K 8 328K 124K 207K 188K 8 32 16K84K 105K 82K 8 32 32K50K 54K 36K 8 32 64K24K 27K 16K 8 32 128K11K 13K 11K We noticed that the requests are not merged by the guest when the multiqueue patches are applied, which results in a regression for small block sizes (RealSSD P320h's optimal block size is around 32-64KB). We observed similar regression for the Dell MZ-5EA1000-0D3 100 GB 2.5 Internal SSD As I understand blk-mq layer bypasses I/O scheduler which also effectively disables merges. Could you explain why it is difficult to enable merging in the blk-mq layer? That could help closing the performance gap we observed. Otherwise, the tests shows that the multiqueue patches does not improve the performance, at least when it comes to sequential read/writes operations. blk-mq still provides merging, there should be no difference there. Does the xen patches set BLK_MQ_F_SHOULD_MERGE? Yes. Is it possible that xen-blkfront driver dequeue requests too fast after we have multiple hardware queues? Because new requests don't have the chance merging with old requests which were already dequeued and issued. For some reason we don't see merges even when we set multiqueue to 1. Below are some stats from the guest system when doing sequential 4KB reads: $ fio --name=test --ioengine=libaio --direct=1 --rw=read --numjobs=8 --iodepth=32 --time_based=1 --runtime=300 --bs=4KB --filename=/dev/xvdb $ iostat -xt 5 /dev/xvdb avg-cpu: %user %nice %system %iowait %steal %idle 0.500.002.73 85.142.009.63 Device: rrqm/s wrqm/s r/s w/s rkB/swkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util xvdb 0.00 0.00 156926.000.00 627704.00 0.00 8.0030.060.190.190.00 0.01 100.48 $ cat /sys/block/xvdb/queue/scheduler none $ cat /sys/block/xvdb/queue/nomerges 0 Relevant bits from the xenstore configuration on the dom0: /local/domain/0/backend/vbd/2/51728/dev = xvdb /local/domain/0/backend/vbd/2/51728/backend-kind = vbd /local/domain/0/backend/vbd/2/51728/type = phy /local/domain/0/backend/vbd/2/51728/multi-queue-max-queues = 1 /local/domain/2/device/vbd/51728/multi-queue-num-queues = 1 /local/domain/2/device/vbd/51728/ring-ref = 9 /local/domain/2/device/vbd/51728/event-channel = 60 If you add --iodepth-batch=16 to that fio command line? Both mq and non-mq relies on plugging to get batching in the use case above, otherwise IO is dispatched immediately. O_DIRECT is immediate. I'd be more interested in seeing a test case with buffered IO of a file system on top of the xvdb device, if we're missing merging for that case, then that's a much bigger issue. I was using the null block driver for xen blk-mq test. There were not merges happen any more even after patch: https://lkml.org/lkml/2015/7/13/185 (Which just converted xen block driver to use blk-mq apis) Will try a file system soon. I have more results for the guest with and without the patch https://lkml.org/lkml/2015/7/13/185 applied to the latest stable kernel (4.1.5). Thank you. Command line used was: fio --name=test --ioengine=libaio --rw=read --numjobs=8 \ --iodepth=32 --time_based=1 --runtime=300 --bs=4KB \ --filename=/dev/xvdb --direct=(0 and 1) --iodepth_batch=16 without patch (--direct=1): xvdb: ios=18696304/0, merge=75763177/0, ticks=11323872/0, in_queue=11344352, util=100.00% with patch (--direct=1): xvdb: ios=43709976/0, merge=97/0, ticks=8851972/0, in_queue=8902928, util=100.00% So request merge can happen just more difficult to be triggered. How about the iops of both cases? Without the patch it is 318Kiops, with
Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatable
On 14.08.15 at 13:52, daniel.ki...@oracle.com wrote: On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote: On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote: diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h index 87b3341..27481ac 100644 --- a/xen/include/asm-x86/page.h +++ b/xen/include/asm-x86/page.h @@ -283,7 +283,7 @@ extern root_pgentry_t idle_pg_table[ROOT_PAGETABLE_ENTRIES]; extern l2_pgentry_t *compat_idle_pg_table_l2; extern unsigned int m2p_compat_vstart; extern l2_pgentry_t l2_xenmap[L2_PAGETABLE_ENTRIES], -l2_bootmap[L2_PAGETABLE_ENTRIES]; +l2_bootmap[4*L2_PAGETABLE_ENTRIES]; ? Why do we need to expand this to be 16kB? TBH, we need 8 KiB in the worst case. The worst case is when next GiB starts (e.g. 1 GiB ends and 2 GiB starts) in the middle of Xen image. In this situation we must hook up lower l2_bootmap table with lower l3_bootmap entry, higher l2_bootmap table with higher l3_bootmap entry and finally fill l2_bootmap relevant tables in proper way. Sadly, this method requires more calculations. To avoid that I have added 3 l2_bootmap tables and simply hook up one after another with relevant l3_bootmap entries. However, if you wish we can reduce number of l2_bootmap tables to two. This way code will be more complicated but we will save about 8 KiB. Wouldn't it be better (simpler) to enforce, say, 16Mb alignment in the PE32+ header (which the EFI loader would then honor)? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xsplice: Use ld-embedded build-ids
On 11.08.2015 16:12, Jan Beulich wrote:
On 05.08.15 at 16:09, mpohl...@amazon.de wrote:
Todo:
* Should be moved to sysctl to only allow Dom0 access
Because of?
The discussion in this thread:
[Xen-devel] [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id
was:
--
Martin Pohlack:
We should not expose the build_id to normal guests, but only to Dom0.
A build_id uniquely identifies a specific build and I don't see how that
information would be required from DomU. It might actually help an
attacker to build his return-oriented programming exploit against a
specific build.
The normal version numbers should be enough to know about capabilities
and API.
Andrew Cooper:
It will need its own XSM hook, but need not be strictly limited to just
dom0.
--
* Maybe convert to binary transport to userland instead of printable form
Indeed.
@@ -360,11 +366,30 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void)
arg)
case XENVER_build_id:
{
-xen_build_id_t build_id;
+xen_build_id_t ascii_id;
+Elf_Note * n = (Elf_Note *)__note_gnu_build_id_start;
+char * binary_id;
+int i;
+
+memset(ascii_id, 0, sizeof(ascii_id));
+
+/* check if we really have a build-id */
+if ( NT_GNU_BUILD_ID != n-type )
+return 0;
This needs to signal an error.
Yes, ENOSYS, (or ENOENT, ENODATA)?
+
+/* sanity check, name should be GNU for ld-generated build-id */
+if ( 0 != strncmp(ELFNOTE_NAME(n), GNU, n-namesz))
+return 0;
Same here.
+binary_id = (char *)ELFNOTE_DESC(n);
+
+/* convert to printable format */
+for (i = 0; i n-descsz (i + 1) * 2 sizeof(xen_build_id_t);
i++)
+{
+snprintf(ascii_id[i * 2], 3, %02hhx, binary_id[i]);
+}
No need for the braces, and no need for thehh modifier.
Jan
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 23/23] x86: add multiboot2 protocol support for relocatable images
On Tue, Aug 11, 2015 at 12:56:58PM -0400, Konrad Rzeszutek Wilk wrote: On Mon, Jul 20, 2015 at 04:29:18PM +0200, Daniel Kiper wrote: Add multiboot2 protocol support for relocatable images. Only GRUB2 with relevant patches understands that feature. Older multiboot You may want to enumerate what those 'relevant' patches are. protocol (regardless of version) compatible loaders ignore it and everything works as usual. Signed-off-by: Daniel Kiper daniel.ki...@oracle.com --- xen/arch/x86/boot/head.S | 46 + xen/arch/x86/x86_64/asm-offsets.c |1 + xen/include/xen/multiboot2.h | 13 +++ 3 files changed, 50 insertions(+), 10 deletions(-) diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S index d484f68..2520e48 100644 --- a/xen/arch/x86/boot/head.S +++ b/xen/arch/x86/boot/head.S @@ -81,6 +81,13 @@ multiboot1_header_end: /* Align modules at page boundry. */ mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED) +/* Load address preference. */ +mb2ht_init MB2_HT(RELOCATABLE), MB2_HT(OPTIONAL), \ + sym_phys(start), /* Min load address. */ \ We could go straight to __start? This specifies lowest load address not entry point. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Redhat 6 VM crash on Xen when cpu number reaches 64
Ouyangzhaowei (Charles) ouyangzhao...@huawei.com writes: Hi all: Now a days, we tested Redhat 6.2(6.4) on Xen(version 4.1.2). If we config the cpu number more than 32, it'll show 32 in the VM, and if we config it 64 cpus, the VM will crash and the log is list below. Can someone tell us why is this happening? Old RHEL6 kernels don't have support for VCPU info placement for PVHVM (VCPUOP_register_vcpu_info call) so only 32 VCPUs are supported. This is fixed in current 6.6.z kernel. Hi Vitaly, Is there any official announcement of this on Redhat website? We did not find any explanation about this, can you help us to find it? As far as I can see this bug didn't make it to the release notes, it is included in the following errata (6.7 kernel update): https://rhn.redhat.com/errata/RHSA-2015-1272.html You can see upstream commit ids in my reply to Konrad: http://lists.xenproject.org/archives/html/xen-devel/2015-08/msg01384.html -- Vitaly ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 1/2] Differentiate IO/mem resources tracked by ioreq server
On 8/14/2015 4:46 PM, Paul Durrant wrote: -Original Message- From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] Sent: 14 August 2015 08:41 To: Paul Durrant; xen-devel@lists.xen.org; Ian Jackson; Stefano Stabellini; Ian Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew Cooper Cc: Kevin Tian; zhiyuan...@intel.com Subject: Re: [Xen-devel] [PATCH v4 1/2] Differentiate IO/mem resources tracked by ioreq server Hi Paul, On 8/13/2015 6:39 PM, Yu, Zhang wrote: On 8/13/2015 6:16 PM, Paul Durrant wrote: -Original Message- From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com] Sent: 13 August 2015 11:06 To: xen-devel@lists.xen.org; Paul Durrant; Ian Jackson; Stefano Stabellini; Ian Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew Cooper Cc: Kevin Tian; zhiyuan...@intel.com Subject: [PATCH v4 1/2] Differentiate IO/mem resources tracked by ioreq server Currently in ioreq server, guest write-protected ram pages are tracked in the same rangeset with device mmio resources. Yet unlike device mmio, which can be in big chunks, the guest write- protected pages may be discrete ranges with 4K bytes each. Would the interfaces be better using xen_pfn_t rather than using uint64_t to pass addresses round where the bottom 12 bits will always be zero? Paul Thank you, Paul. Well, I'm not quite sure if the bottom 12 bits of the address are zero. I had thought these addresses are just guest physical ones causing the ept violation, and not aligned down to its page address, like the MMIO. So, if our handler code has already done that, using xen_pfn_t could be better(my developing machine encountered some hardware problem, will check the code tomorrow) :) Yu I just checked the code in hvm_select_ioreq_server(), and found value of address is not aligned down, and the lower 12 bits are not zero. So I wonder, is it necessary to do the shift to get a gfn, and what's the benefit? Well, you can only make whole pages mmio_dm_write and I was assuming an emulator that did so would be interested in writes anywhere in the page. Maybe that assumption is wrong? Paul Thank you, Paul. That makes sense. I'll try use the xen_pfn_t. :-) Yu Thanks Yu This patch uses a seperate rangeset for the guest ram pages. And a new ioreq type, IOREQ_TYPE_WP_MEM, is defined. Note: Previously, a new hypercall or subop was suggested to map write-protected pages into ioreq server. However, it turned out handler of this new hypercall would be almost the same with the existing pair - HVMOP_[un]map_io_range_to_ioreq_server, and there's already a type parameter in this hypercall. So no new hypercall defined, only a new type is introduced. Signed-off-by: Yu Zhang yu.c.zh...@linux.intel.com --- tools/libxc/include/xenctrl.h| 31 ++ tools/libxc/xc_domain.c | 55 xen/arch/x86/hvm/hvm.c | 26 ++- xen/include/asm-x86/hvm/domain.h | 4 +-- xen/include/public/hvm/hvm_op.h | 1 + xen/include/public/hvm/ioreq.h | 1 + 6 files changed, 115 insertions(+), 3 deletions(-) diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h index de3c0ad..53f196d 100644 --- a/tools/libxc/include/xenctrl.h +++ b/tools/libxc/include/xenctrl.h @@ -2010,6 +2010,37 @@ int xc_hvm_unmap_io_range_from_ioreq_server(xc_interface *xch, int is_mmio, uint64_t start, uint64_t end); +/** + * This function registers a range of write-protected memory for emulation. + * + * @parm xch a handle to an open hypervisor interface. + * @parm domid the domain id to be serviced + * @parm id the IOREQ Server id. + * @parm start start of range + * @parm end end of range (inclusive). + * @return 0 on success, -1 on failure. + */ +int xc_hvm_map_mem_range_to_ioreq_server(xc_interface *xch, +domid_t domid, +ioservid_t id, +uint64_t start, +uint64_t end); + +/** + * This function deregisters a range of write-protected memory for emulation. + * + * @parm xch a handle to an open hypervisor interface. + * @parm domid the domain id to be serviced + * @parm id the IOREQ Server id. + * @parm start start of range + * @parm end end of range (inclusive). + * @return 0 on success, -1 on failure. + */ +int xc_hvm_unmap_mem_range_from_ioreq_server(xc_interface *xch, +domid_t domid, +ioservid_t id, +uint64_t start, +uint64_t end); /** * This function registers a PCI device for config space emulation. diff --git a/tools/libxc/xc_domain.c
[Xen-devel] [PATCH] xen/x86: Clean up vm_event-related code in asm-x86/domain.h
As suggested by Jan Beulich, moved struct monitor_write_data from
struct arch_domain to struct arch_vcpu, as well as moving all
vm_event-related data from asm-x86/domain.h to struct vm_event,
and allocating it dynamically only when needed.
Signed-off-by: Razvan Cojocaru rcojoc...@bitdefender.com
---
xen/arch/x86/domain.c| 10 ++
xen/arch/x86/hvm/emulate.c |6 +++---
xen/arch/x86/hvm/hvm.c | 32
xen/arch/x86/mm/p2m.c| 24
xen/arch/x86/vm_event.c | 26 +++---
xen/include/asm-x86/domain.h | 26 ++
6 files changed, 54 insertions(+), 70 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 045f6ff..58e173e 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -424,9 +424,6 @@ int vcpu_initialise(struct vcpu *v)
v-arch.flags = TF_kernel_mode;
-/* By default, do not emulate */
-v-arch.vm_event.emulate_flags = 0;
-
rc = mapcache_vcpu_init(v);
if ( rc )
return rc;
@@ -511,8 +508,8 @@ int vcpu_initialise(struct vcpu *v)
void vcpu_destroy(struct vcpu *v)
{
-xfree(v-arch.vm_event.emul_read_data);
-v-arch.vm_event.emul_read_data = NULL;
+xfree(v-arch.vm_event);
+v-arch.vm_event = NULL;
if ( is_pv_32bit_vcpu(v) )
{
@@ -668,9 +665,6 @@ int arch_domain_create(struct domain *d, unsigned int
domcr_flags,
void arch_domain_destroy(struct domain *d)
{
-vfree(d-arch.event_write_data);
-d-arch.event_write_data = NULL;
-
if ( has_hvm_container_domain(d) )
hvm_domain_destroy(d);
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 30acb78..d0f98c8 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -71,12 +71,12 @@ static int set_context_data(void *buffer, unsigned int size)
{
struct vcpu *curr = current;
-if ( curr-arch.vm_event.emul_read_data )
+if ( curr-arch.vm_event )
{
unsigned int safe_size =
-min(size, curr-arch.vm_event.emul_read_data-size);
+min(size, curr-arch.vm_event-emul_read_data.size);
-memcpy(buffer, curr-arch.vm_event.emul_read_data-data, safe_size);
+memcpy(buffer, curr-arch.vm_event-emul_read_data.data, safe_size);
memset(buffer + safe_size, 0, size - safe_size);
return X86EMUL_OKAY;
}
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c957610..9bc698c 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -541,9 +541,9 @@ void hvm_do_resume(struct vcpu *v)
break;
}
-if ( unlikely(d-arch.event_write_data) )
+if ( unlikely(v-arch.vm_event) )
{
-struct monitor_write_data *w = d-arch.event_write_data[v-vcpu_id];
+struct monitor_write_data *w = v-arch.vm_event-write_data;
if ( w-do_write.msr )
{
@@ -571,7 +571,7 @@ void hvm_do_resume(struct vcpu *v)
}
/* Inject pending hw/sw trap */
-if ( v-arch.hvm_vcpu.inject_trap.vector != -1 )
+if ( v-arch.hvm_vcpu.inject_trap.vector != -1 )
{
hvm_inject_trap(v-arch.hvm_vcpu.inject_trap);
v-arch.hvm_vcpu.inject_trap.vector = -1;
@@ -3371,13 +3371,13 @@ int hvm_set_cr0(unsigned long value, bool_t may_defer)
monitor_ctrlreg_bitmask(VM_EVENT_X86_CR0))
value != old_value )
{
-ASSERT(currad-event_write_data != NULL);
+ASSERT(v-arch.vm_event != NULL);
if ( hvm_event_crX(CR0, value, old_value) )
{
/* The actual write will occur in hvm_do_resume(), if permitted. */
-currad-event_write_data[v-vcpu_id].do_write.cr0 = 1;
-currad-event_write_data[v-vcpu_id].cr0 = value;
+v-arch.vm_event-write_data.do_write.cr0 = 1;
+v-arch.vm_event-write_data.cr0 = value;
return X86EMUL_OKAY;
}
@@ -3475,13 +3475,13 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3))
value != old )
{
-ASSERT(currad-event_write_data != NULL);
+ASSERT(v-arch.vm_event != NULL);
if ( hvm_event_crX(CR3, value, old) )
{
/* The actual write will occur in hvm_do_resume(), if permitted. */
-currad-event_write_data[v-vcpu_id].do_write.cr3 = 1;
-currad-event_write_data[v-vcpu_id].cr3 = value;
+v-arch.vm_event-write_data.do_write.cr3 = 1;
+v-arch.vm_event-write_data.cr3 = value;
return X86EMUL_OKAY;
}
@@ -3549,13 +3549,13 @@ int hvm_set_cr4(unsigned long value, bool_t may_defer)
monitor_ctrlreg_bitmask(VM_EVENT_X86_CR4))
value != old_cr )
{
-ASSERT(currad-event_write_data != NULL);
+ASSERT(v-arch.vm_event != NULL);
if (
Re: [Xen-devel] [xen-4.4-testing test] 60673: regressions - FAIL
On 14.08.15 at 11:14, osstest-ad...@xenproject.org wrote: flight 60673 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/60673/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail REGR. vs. 60152 Iirc this same test has been failing here and there a number of times recently - is this a sign of some issue unrelated to the software under test? If so, I'd be inclined to suggest a force push based on this flight. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/x86: Clean up vm_event-related code in asm-x86/domain.h
On 14.08.15 at 11:54, rcojoc...@bitdefender.com wrote:
@@ -571,7 +571,7 @@ void hvm_do_resume(struct vcpu *v)
}
/* Inject pending hw/sw trap */
-if ( v-arch.hvm_vcpu.inject_trap.vector != -1 )
+if ( v-arch.hvm_vcpu.inject_trap.vector != -1 )
Stray whitespace change to unrelated code.
@@ -3371,13 +3371,13 @@ int hvm_set_cr0(unsigned long value, bool_t
may_defer)
monitor_ctrlreg_bitmask(VM_EVENT_X86_CR0))
value != old_value )
{
-ASSERT(currad-event_write_data != NULL);
+ASSERT(v-arch.vm_event != NULL);
May I recommend dropping the redundant != NULL namely in ASSERT()
expressions (the only effect they have is produce larger string literals
in debug builds).
if ( hvm_event_crX(CR0, value, old_value) )
{
/* The actual write will occur in hvm_do_resume(), if permitted.
*/
-currad-event_write_data[v-vcpu_id].do_write.cr0 = 1;
-currad-event_write_data[v-vcpu_id].cr0 = value;
+v-arch.vm_event-write_data.do_write.cr0 = 1;
+v-arch.vm_event-write_data.cr0 = value;
Looks like this leaves just a single use of currad in the function, in
which case I'd like to see the variable go away.
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -8,6 +8,7 @@
#include asm/hvm/domain.h
#include asm/e820.h
#include asm/mce.h
+#include public/vm_event.h
It looks like both this and ...
@@ -460,6 +459,18 @@ typedef enum __packed {
SMAP_CHECK_DISABLED,/* disable the check */
} smap_check_policy_t;
+/*
+ * Should we emulate the next matching instruction on VCPU resume
+ * after a vm_event?
+ */
+struct vm_event {
+uint32_t emulate_flags;
+unsigned long gpa;
+unsigned long eip;
+struct vm_event_emul_read_data emul_read_data;
+struct monitor_write_data write_data;
+};
... this would better go into asm-x86/vm_event.h (despite it meaning
that the file will then be included by basically everything).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 0/2] Port two ACPI fixes from Linux
On 14.08.15 at 05:36, zhaoshengl...@huawei.com wrote: From: Shannon Zhao shannon.z...@linaro.org Len Brown (1): ACPI: disable ACPI cleanly when bad RSDP found Tomasz Nowicki (1): ACPI/table: Always count matched and successfully parsed entries These look good now, but is there a reason you didn't also port the third commit I had referred you to (95df812dbd)? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/x86: Clean up vm_event-related code in asm-x86/domain.h
On 08/14/2015 01:21 PM, Jan Beulich wrote:
On 14.08.15 at 11:54, rcojoc...@bitdefender.com wrote:
@@ -571,7 +571,7 @@ void hvm_do_resume(struct vcpu *v)
}
/* Inject pending hw/sw trap */
-if ( v-arch.hvm_vcpu.inject_trap.vector != -1 )
+if ( v-arch.hvm_vcpu.inject_trap.vector != -1 )
Stray whitespace change to unrelated code.
Understood, thought I'd remove the trailing whitespace there, but I will
leave the unrelated code alone.
@@ -3371,13 +3371,13 @@ int hvm_set_cr0(unsigned long value, bool_t
may_defer)
monitor_ctrlreg_bitmask(VM_EVENT_X86_CR0))
value != old_value )
{
-ASSERT(currad-event_write_data != NULL);
+ASSERT(v-arch.vm_event != NULL);
May I recommend dropping the redundant != NULL namely in ASSERT()
expressions (the only effect they have is produce larger string literals
in debug builds).
Of course, I'll change it.
if ( hvm_event_crX(CR0, value, old_value) )
{
/* The actual write will occur in hvm_do_resume(), if
permitted. */
-currad-event_write_data[v-vcpu_id].do_write.cr0 = 1;
-currad-event_write_data[v-vcpu_id].cr0 = value;
+v-arch.vm_event-write_data.do_write.cr0 = 1;
+v-arch.vm_event-write_data.cr0 = value;
Looks like this leaves just a single use of currad in the function, in
which case I'd like to see the variable go away.
I'll remove it.
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -8,6 +8,7 @@
#include asm/hvm/domain.h
#include asm/e820.h
#include asm/mce.h
+#include public/vm_event.h
It looks like both this and ...
@@ -460,6 +459,18 @@ typedef enum __packed {
SMAP_CHECK_DISABLED,/* disable the check */
} smap_check_policy_t;
+/*
+ * Should we emulate the next matching instruction on VCPU resume
+ * after a vm_event?
+ */
+struct vm_event {
+uint32_t emulate_flags;
+unsigned long gpa;
+unsigned long eip;
+struct vm_event_emul_read_data emul_read_data;
+struct monitor_write_data write_data;
+};
... this would better go into asm-x86/vm_event.h (despite it meaning
that the file will then be included by basically everything).
Ack. Thank you for the prompt review!
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
