Re: [Xen-devel] Install of Xen 4.8 on Fedora 25 makes the box unbootable.. which is due to /var/run/xen being created, instead of /run/xen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Thu, 16 Feb 2017 08:58:01 +0100 schrieb Juergen Gross : > You can't assume ./configure is running on the same system as Xen is > being built for. I think its easy to decide at build time if the target has and/or uses "/run". And this will not change suddenly later at runtime. Olaf -BEGIN PGP SIGNATURE- iF0EARECAB0WIQSkRyP6Rn//f03pRUBdQqD6ppg2fgUCWKVc2AAKCRBdQqD6ppg2 fmDLAJoCBNtcIxqEigAuoaGyx6Ngg7WxBgCfUK3MiGAQ2H/s7drKLVyJL42H6eg= =reRA -END PGP SIGNATURE- ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Install of Xen 4.8 on Fedora 25 makes the box unbootable.. which is due to /var/run/xen being created, instead of /run/xen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Thu, 16 Feb 2017 08:58:01 +0100 schrieb Juergen Gross : > You can't assume ./configure is running on the same system as Xen is > being built for. I think its easy to decide at build time if the target has and/or uses "/run". And this will not change suddenly later at runtime. Olaf -BEGIN PGP SIGNATURE- iF0EARECAB0WIQSkRyP6Rn//f03pRUBdQqD6ppg2fgUCWKVdPgAKCRBdQqD6ppg2 fmezAJ4k7QbZhloBUVy6h+JUna2nlfcXzwCfZEdNpin6GxAKDxokfQBSkpeKI1c= =K0t9 -END PGP SIGNATURE- ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] VMX: fix VMCS race on context-switch paths
On Wed, 2017-02-15 at 08:15 -0700, Jan Beulich wrote:
> > > > On 15.02.17 at 15:55, wrote:
> >
> > On Wed, 2017-02-15 at 06:20 -0700, Jan Beulich wrote:
> > > > > > On 15.02.17 at 11:27, wrote:
> > > >
> > > > This is what I'm getting during the original test case (32 VMs reboot):
> > > >
> > > > (XEN) [ 1407.789329] Watchdog timer detects that CPU12 is stuck!
> > > > (XEN) [ 1407.795726] [ Xen-4.6.1-xs-local x86_64 debug=n Not
> > > > tainted ]
> > >
> > > Hmm, this was with a non-debug build, so the ASSERT() in
> > > vmx_vmcs_reload() was a no-op, yet it would have been useful
> > > to know whether active_cpu was -1 when getting stuck here.
> > > Btw - there was no nested virt in the picture in your try, was
> > > there?
> >
> > No nested virt is involved in the test case.
> >
> > Is it worth giving your patch another try with removing ctxt_switch_same()
> > since we figured out that vmx_do_resume() will reload vmcs either way?
>
> Yes, but that's the cosmetic part, whereras ...
>
> > And I will also update vmx_vmcs_reload() from your last email.
>
> ... this looks to be the actual bug fix. If you agree with my
> reasoning of removing the loop altogether, you may want to go
> with that version instead of adding the conditional.
After extensive night testing, it can be safe to assume that below
patch fixes the PML issue. I agree about removing the spinning since
vmx_vmcs_enter/exit are synchronized with the scheduler by schedule_lock.
But it costs nothing to check so I added a debug message to the loop.
Needless to say, it was never printed.
My patch for vmx_vmcs_exit() is obviously a half measure because it
doesn't protect against VMCS clearing by an external IPI when current
is idle. I'm not sure such situation is possible but there is nothing
that prevents it.
This clearly makes your approach superior and I think you need to
submit v2 for proper review.
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 88db7ee..07e8527 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -551,6 +551,33 @@ static void vmx_load_vmcs(struct vcpu *v)
local_irq_restore(flags);
}
+void vmx_vmcs_reload(struct vcpu *v)
+{
+/*
+ * As we're running with interrupts disabled, we can't acquire
+ * v->arch.hvm_vmx.vmcs_lock here. However, with interrupts disabled
+ * the VMCS can't be taken away from us anymore if we still own it.
+ */
+ASSERT(!local_irq_is_enabled());
+if ( v->arch.hvm_vmx.vmcs == this_cpu(current_vmcs) )
+return;
+ASSERT(!this_cpu(current_vmcs));
+
+if ( v->arch.hvm_vmx.active_cpu != smp_processor_id() )
+{
+/*
+ * Wait for the remote side to be done with the VMCS before loading
+ * it here.
+ */
+while ( v->arch.hvm_vmx.active_cpu != -1 ) {
+printk("DS: v->arch.hvm_vmx.active_cpu == %d\n",
+v->arch.hvm_vmx.active_cpu);
+cpu_relax();
+}
+}
+vmx_load_vmcs(v);
+}
+
int vmx_cpu_up_prepare(unsigned int cpu)
{
/*
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 8cafec2..ccf433f 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -734,6 +734,18 @@ static void vmx_ctxt_switch_from(struct vcpu *v)
if ( unlikely(!this_cpu(vmxon)) )
return;
+if ( !v->is_running )
+{
+/*
+ * When this vCPU isn't marked as running anymore, a remote pCPU's
+ * attempt to pause us (from vmx_vmcs_enter()) won't have a reason
+ * to spin in vcpu_sleep_sync(), and hence that pCPU might have taken
+ * away the VMCS from us. As we're running with interrupts disabled,
+ * we also can't call vmx_vmcs_enter().
+ */
+vmx_vmcs_reload(v);
+}
+
vmx_fpu_leave(v);
vmx_save_guest_msrs(v);
vmx_restore_host_msrs();
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h
b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 5974cce..2bf8829 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -157,6 +157,7 @@ void vmx_destroy_vmcs(struct vcpu *v);
void vmx_vmcs_enter(struct vcpu *v);
bool_t __must_check vmx_vmcs_try_enter(struct vcpu *v);
void vmx_vmcs_exit(struct vcpu *v);
+void vmx_vmcs_reload(struct vcpu *v);
#define CPU_BASED_VIRTUAL_INTR_PENDING0x0004
#define CPU_BASED_USE_TSC_OFFSETING 0x0008
--
Thanks,
Sergey
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] displif: add ABI for para-virtual display
On 02/15/2017 11:33 PM, Konrad Rzeszutek Wilk wrote: .snip.. I will define 2 sections: *-- Connector Request Transport Parameters --- * * ctrl-event-channel * ctrl-ring-ref * *--- Connector Event Transport Parameters * * event-channel * event-ring-ref Or is the other ring buffer the one that is created via 'gref_directory' ? no At the bottom: * In order to deliver asynchronous events from back to front a shared page is * allocated by front and its gref propagated to back via XenStore entries * (event-XXX). AAnd you may want to say this is guarded by REQ_ALLOC feature right? Not sure I understood you. Event path is totally independent from any feature, e.g. REQ_ALLOC. It just provides means to send async events from back to front, "page flip done" in my case. Why do you need a seperate ring to send responses back? Why not use the same ring on which requests were sent Ok, it seems we are not on the same page for rings/channels usage. Let me describe how those are used: 1. Command/control event channel and its corresponding ring are used to pass requests from front to back (XENDISPL_OP_XXX) and get responses from the back. These are synchronous, use macros from ring.h: ctrl-event-channel + ctrl-ring-ref I call them "ctrl-" because this way front controls back, or sends commands if you will. Maybe "cmd-" would fit better here? 2. Event channel - asynchronous path for the backend to signal activity to the frontend, currently used for "page flip done" event which is sent at some point of time after back has actually completed the page flip requested (so, before that the corresponding request was sent and response received, but operation didn't complete yet, instead it was scheduled) No macros exist for this use-case in ring.h (kbdif+fbif implement this on their own, so do I) These are: event-channel + event-ring-ref Probably here is the point from where confusion comes, naming. We can have something like "be-to-fe-event-channel" or anything else more cute and descriptive. Hope this explains the need for 2 paths Aha! So this is like the network where there is an 'rx' and 'tx'! kind of Now I get it. sorry, I was probably not clear In that case why not just prefix it with 'in' and 'out'? Such as: 'out-ring-ref' and 'out-event-channel' and 'in-ring-ref' along with 'in-event-channel'. h, it may confuse, because you must know "out" from which POV, e.g. frontend's or backend's. What is more, these "out-" and "in-" are... nameless? Can we still have something like "ctrl-"/"cmd-"/"req-" for the req/resp path and probably "evt-" for events from back to front? Or perhaps better - borrow the same idea that Stefano came up for 9pfs and PV calls - where his ring does both. Then you just need 'ring-ref', 'event-channel', 'max-page-ring-order' (which must be 1 or larger). And you split the ring-ref in two - one for 'in' events and the other part for 'out' events? yes, I saw current implementations (kbdif, fbif) and what Stefano did, but would rather stick to what is currently defined (I believe it is optimal as is) And hope, that maybe someone will put new functionality into ring.h to serve async events one day :) ..giant snip.. Thus, I was thinking of XenbusStateReconfiguringstate as appropriate in this case Right, but somebody has to move to this state. Who would do it? when backend dies its state changes to "closed". At this moment front tries to remove virtualized device and if it is possible/done, then it goes into "initialized" state. If not - "reconfiguring". So, you would ask how does the front go from "reconfiguring" into "initialized" state? This is OS/front specific, but: 1. the underlying framework, e.g. DRM/KMS, ALSA, provide a callback(s) to signal that the last client to the virtualized device has gone and the driver can be removed (equivalent to module's usage counter 0) 2. one can schedule a delayed work (timer/tasklet/workqueue) to periodically check if this is the right time to re-try the removal and remove In both cases, after the virtualized device has been removed we move into "initialized" state again and are ready for new connections with backend (if it arose from the dead :) Would the frontend have some form of timer to make sure that the backend is still alive? And if it had died then move to Reconfiguring? There are at least 2 ways to understand if back is dead: 1. XenBus state change (back is closed) .. If the backend does a nice shutdown.. hm, on Linux I can kill -9 backend and XenBus driver seems to be able to turn back's state into "closed" isn't this expected behavior? That is the expected behavior. I was thinking more of a backend being a guest - and the guest completly going away and nobody clearing its XenStore keys. In which case your second option of doing a timeout will work. But you may need an 'PING' type request to figure this o
Re: [Xen-devel] [PATCH 1/3] xen/include: Remove explicit xen/config.h includes
Hi Andrew, On 15/02/2017 18:10, Andrew Cooper wrote: This file is included automatically via CFLAGS. Signed-off-by: Andrew Cooper For the ARM bits: Acked-by: Julien Grall Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/3] xen/include: Remove explicit asm/config.h includes
Hi Andrew, On 15/02/2017 18:10, Andrew Cooper wrote: xen/config.h includes asm/config.h, and is included automatically via CFLAGS. Signed-off-by: Andrew Cooper Acked-by: Julien Grall Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] xen/include: Include xen/kconfig.h automatically
Hi Andrew, On 15/02/2017 18:10, Andrew Cooper wrote: generated/autoconf.h is already included automatically so CONFIG_* defines are avaialble. However, the companion macros such as IS_ENABLED() are not NIT: s/avaialble/available/ included. Include them uniformally everywhere. Signed-off-by: Andrew Cooper Acked-by: Julien Grall Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] backport of "x86/hvm: don't rely on shared ioreq state for completion handling" ?
Paul, as it looks to be quite non-trivial an operation, did you happen to have to backport commit 480b83162a to 4.4 or older, without backporting all the ioreq server stuff at the same time? It looks to me as if the issue predates the addition of ioreq servers, and us having had customer reports here would seem to make this a candidate fix (perhaps with at least 125833f5f1 ["x86: fix ioreq-server event channel vulnerability"] also backported, which also appears to address a pre-existing issue). Thanks, Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] VMX: fix VMCS race on context-switch paths
>>> On 16.02.17 at 09:29, wrote: > On Wed, 2017-02-15 at 08:15 -0700, Jan Beulich wrote: >> > > > On 15.02.17 at 15:55, wrote: >> > Is it worth giving your patch another try with removing ctxt_switch_same() >> > since we figured out that vmx_do_resume() will reload vmcs either way? >> >> Yes, but that's the cosmetic part, whereras ... >> >> > And I will also update vmx_vmcs_reload() from your last email. >> >> ... this looks to be the actual bug fix. If you agree with my >> reasoning of removing the loop altogether, you may want to go >> with that version instead of adding the conditional. > > After extensive night testing, it can be safe to assume that below > patch fixes the PML issue. I agree about removing the spinning since > vmx_vmcs_enter/exit are synchronized with the scheduler by schedule_lock. > But it costs nothing to check so I added a debug message to the loop. > Needless to say, it was never printed. Thanks, that's good to know. I'll remove the loop in v2. > My patch for vmx_vmcs_exit() is obviously a half measure because it > doesn't protect against VMCS clearing by an external IPI when current > is idle. I'm not sure such situation is possible but there is nothing > that prevents it. > > This clearly makes your approach superior and I think you need to > submit v2 for proper review. Will do. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Install of Xen 4.8 on Fedora 25 makes the box unbootable.. which is due to /var/run/xen being created, instead of /run/xen
On Thu, 16 Feb 2017, Juergen Gross wrote: > On 16/02/17 08:52, Olaf Hering wrote: > > Am Wed, 15 Feb 2017 15:51:12 -0500 > > schrieb Konrad Rzeszutek Wilk : > >> mkdir /run/xen > >> mkdir /run/xenstored > > > > This must be done by the startup scripts because the "run" directories, > > where ever they are, are volatile. > > > > I think confiugre should check if "/run" exists and assume this is a > > systemd based system and adjust the Makefile variables to be > > either /var/run or /run. > > You can't assume ./configure is running on the same system as Xen is > being built for. > > Just sent a patch adding "--with-rundir" parameter to configure. Build time detection makes sense to determine the default setting, but there should probably be an option to override it for when you are building in one environment for use in a different one. Michael Young ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v15 05/10] x86: add multiboot2 protocol support for EFI platforms
>>> On 15.02.17 at 22:53, wrote: > On Wed, Feb 15, 2017 at 03:22:02AM -0700, Jan Beulich wrote: >> >>> On 14.02.17 at 19:38, wrote: >> > --- a/xen/arch/x86/boot/head.S >> > +++ b/xen/arch/x86/boot/head.S >> > @@ -394,10 +394,18 @@ __start: >> > >> > /* EFI IA-32 platforms are not supported. */ >> > cmpl$MULTIBOOT2_TAG_TYPE_EFI32,MB2_tag_type(%ecx) >> > +/* >> > + * Here we should zap vga_text_buffer. However, we can disable >> > + * VGA updates in simpler and more reliable way later. >> > + */ >> > je .Lmb2_efi_ia_32 >> > >> > /* Bootloader shutdown EFI x64 boot services. */ >> > cmpl$MULTIBOOT2_TAG_TYPE_EFI64,MB2_tag_type(%ecx) >> > +/* >> > + * Here we should zap vga_text_buffer. However, we can disable >> > + * VGA updates in simpler and more reliable way later. >> > + */ >> > je .Lmb2_no_bs >> >> I'm afraid I don't view these comments as helpful in understanding >> the whole situation. That's partly because I don't follow both the >> "simpler" and "more reliable" parts (using just the information here, > > OK, I will clarify it. > >> i.e. leaving aside what you've given as explanation earlier, albeit I >> don't think that was fully clarifying things either), and partly >> because I continue to think that the explanation should go where >> the labels are (which is what I had meant to suggest with my >> comment placement in reply to v14). Nor does the adjustment > > OK. > >> above help (me) understand the correctness of the dual use of >> .Lmb2_no_bs. > > What do you mean by "dual use of .Lmb2_no_bs."? I would like to be sure. As said in v14 review, it's being jumped to from two rather different places, and hence the VGA aspect isn't obviously the same for both. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Unable to boot Xen 4.8 with iommu=0
>>> On 15.02.17 at 20:30, wrote: > On Wed, Feb 15, 2017 at 3:03 AM, Jan Beulich wrote: > On 15.02.17 at 00:21, wrote: >>> On 14/02/2017 22:47, Tamas K Lengyel wrote: (XEN) Switched to APIC driver x2apic_cluster. (XEN) XSM Framework v1.0.0 initialized (XEN) Flask: 128 avtab hash slots, 394 rules. (XEN) Flask: 128 avtab hash slots, 394 rules. (XEN) Flask: 5 users, 3 roles, 43 types, 2 bools (XEN) Flask: 12 classes, 394 rules (XEN) Flask: Starting in enforcing mode. (XEN) xstate: size: 0x340 and states: 0x7 (XEN) Intel machine check reporting enabled (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Platform timer is 14.318MHz HPET (XEN) Detected 3392.326 MHz processor. (XEN) Initing memory sharing. (XEN) alt table 82d0802d3f38 -> 82d0802d5564 (XEN) PCI: MCFG configuration 0: base e000 segment buses 00 - 3f (XEN) PCI: Not using MCFG for segment bus 00-3f (XEN) (XEN) (XEN) Panic on CPU 0: (XEN) Couldn't enable IOMMU and iommu=required/force (XEN) (XEN) (XEN) Reboot in five seconds... (XEN) Resetting with ACPI MEMORY or I/O RESET_REG. As seen in the command line iommu is not set to required or forced. Yet Xen thinks it is set to required/force. Has anyone else run into this issue? >>> >>> This area is a rats nest :( >>> >>> The problem is that the APIC setup has chosen to use the x2apic_cluster >>> driver, which in the Xen code depends on x2APIC, which depends on >>> interrupt remapping, which depends on an IOMMU. >>> >>> (I could have sworn we fixed this before), but the bug is that the APIC >>> setup shouldn't choose any of the x2apic modes if there isn't an >>> interrupt remapping capable IOMMU. >> >> And from going over the code I can't see how this would happen, >> so Tamas, it would be nice if you could add some verbosity to the >> functions involved. In particular x2apic_bsp_setup() must be >> getting success (zero) from iommu_enable_x2apic_IR(), yet that >> function calls iommu_supports_eim(), which ought to produce >> false through its very first exit path in your case. >> >> Or wait - do you have the same issue if you use >> "iommu=no,no-intremap"? In which case the problem would be >> that "iommu=no" should clear more than just "iommu_enable", or >> code checking iommu_intremap early (before iommu_setup() >> manages to clear it in the case here) would need to made look at >> both variables. Oddly enough acpi_parse_dmar() only bails if >> both variables are clear, which suggests to me that >> iommu_enable is intended to have two different meanings in >> different contexts (master flag vs. controlling just DMA >> remapping). Kevin, Feng - any thoughts here? > > iommu=no,no-intremap boots fine with "(XEN) Using APIC driver default" Thanks for confirming. Kevin, Feng, we now depend on your input regarding the intentions with the two variables. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: increase default dom0_mem to 512M
Hi Stefano,
On 15/02/2017 23:05, Stefano Stabellini wrote:
The default dom0_mem is 128M which is not sufficient to boot a Ubuntu
based Dom0. Increase it to 512M.
Signed-off-by: Stefano Stabellini
I am not a big fan of increasing the default value. 128M is plenty
enough if you use a small DOM0 (e.g buildroot or yocto) and people may
rely on it because it is the default value in the documentation
(see docs/misc/xen-command-line.markdown).
Also, 512M may boot Ubuntu for you but it might not be the case in all
the configuration. There is no perfect default value, but I think the
smaller is better. Looking at the documentation, it looks like x86 is
using 128MB or 1/16 of the memory (whichever is smaller).
But to be fair, I am not even sure why there is a default value, it is
quite easy to specify the amount of memory used by DOM0 on the command line.
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c97a1f5..f4612a2 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -31,7 +31,7 @@ integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
int dom0_11_mapping = 1;
-#define DOM0_MEM_DEFAULT 0x800 /* 128 MiB */
+#define DOM0_MEM_DEFAULT 0x2000 /* 512 MiB */
I would use the MB(..) macro here to make the code more readable.
static u64 __initdata dom0_mem = DOM0_MEM_DEFAULT;
static void __init parse_dom0_mem(const char *s)
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Unshared IOMMU issues
>>> On 15.02.17 at 18:43, wrote: > 1. > I need: > Allow P2M core on ARM to update IOMMU mapping from the first "p2m_set_entry". > I do: > I explicitly set need_iommu flag for *every* guest domain during > iommu_domain_init() on ARM in case if page table is not shared. > At that moment I have no knowledge about will any device be assigned > to this domain or not. I am just want to receive all mapping updates > from P2M code. The P2M will update IOMMU mapping only when need_iommu > is set and page table is not shared. > I have doubts: > Is it correct to just force need_iommu flag? No, I don't think so. This is a waste of a measurable amount of resources when page tables aren't shared. > Or maybe another flag should be introduced? Not sure what you think of here. Where's the problem with building IOMMU page tables at the time the first device gets assigned, just like x86 does? > Or we don't need to check for need_iommu flag before updating IOMMU > mapping in P2M code, maybe iommu_enabled would be enough? No, afaict that would again mean maintaining IOMMU page tables regardless of whether they're needed. > 2. > I need: > Allow IOMMU driver to be ready to handle IOMMU mapping updates from > the first "p2m_set_entry". Why (see also the question above)? > I do: > I always allocate IOMMU page table during iommu_domain_init() for every > domain even this domain won't have any assigned devices in future. I > don't wait for iommu_construct. > I have doubts: > Is it correct? It might be just wasting memory and CPU time if domain > doesn't have any assigned devices in future. Indeed. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] ACPICA: ACPI 6.0: Add support for IORT table.
>>> On 15.02.17 at 23:34, wrote: > From: Lv Zheng > > ACPICA commit 5de82757aef5d6163e37064033aacbce193abbca > > This patch adds support for IORT (IO Remapping Table) in iasl. > > Note that some field names are modified to shrink their length or the > decompiled IORT ASL will contain fields with ugly ":" alignment. > > The IORT contains field definitions around "Memory Access Properties". This > patch also adds support to encode/decode it using inline table. > > This patch doesn't add inline table support for the SMMU interrupt fields > due to a limitation in current ACPICA data table support. Lv Zheng. > > Link: https://github.com/acpica/acpica/commit/5de82757 > Signed-off-by: Lv Zheng > Signed-off-by: Bob Moore > Signed-off-by: Rafael J. Wysocki > [Linux commit 874f6a723e56d0da9e481629b17482bcd3801ecf] > [only port the IORT changes] > Signed-off-by: Sameer Goel While you've Cc-ed quite a few people, you didn't Cc the Xen side maintainers of the code you change. Plus with this not being part of a series, it would also help if you clarified what the change is going to be needed for, as on its own it'll be an addition of dead code. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] backport of "x86/hvm: don't rely on shared ioreq state for completion handling" ?
> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 16 February 2017 09:21 > To: Paul Durrant > Cc: xen-devel > Subject: backport of "x86/hvm: don't rely on shared ioreq state for > completion handling" ? > > Paul, > > as it looks to be quite non-trivial an operation, did you happen to > have to backport commit 480b83162a to 4.4 or older, without > backporting all the ioreq server stuff at the same time? It looks to > me as if the issue predates the addition of ioreq servers, and us > having had customer reports here would seem to make this a > candidate fix (perhaps with at least 125833f5f1 ["x86: fix > ioreq-server event channel vulnerability"] also backported, which > also appears to address a pre-existing issue). > Hi Jan, Sorry, no I don't have a back-port. Agreed that the issue existed prior to ioreq servers but the checking was probably sufficiently lax that it never resulted in a domain_crash(), just bad data coming back from an emulation request. Paul > Thanks, Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] backport of "x86/hvm: don't rely on shared ioreq state for completion handling" ?
>>> On 16.02.17 at 11:13, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 16 February 2017 09:21 >> >> as it looks to be quite non-trivial an operation, did you happen to >> have to backport commit 480b83162a to 4.4 or older, without >> backporting all the ioreq server stuff at the same time? It looks to >> me as if the issue predates the addition of ioreq servers, and us >> having had customer reports here would seem to make this a >> candidate fix (perhaps with at least 125833f5f1 ["x86: fix >> ioreq-server event channel vulnerability"] also backported, which >> also appears to address a pre-existing issue). > > Sorry, no I don't have a back-port. Agreed that the issue existed prior to > ioreq servers but the checking was probably sufficiently lax that it never > resulted in a domain_crash(), just bad data coming back from an emulation > request. Well, according to the reports we've got, maybe it was less likely to trigger, but it looks like it wasn't lax enough. Albeit I'm yet to get confirmation that the issue was only seen during domain shutdown, which aiui was (leaving aside a guest fiddling with the shared structure, in which case it deserves being crashed) the only condition triggering that domain_crash(). Once I have aforementioned confirmation, would you mind if I asked you to look over the backports, should I manage to create them in the first place? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] xen/sched.h Whitespace and bool cleanup
>>> On 15.02.17 at 18:39, wrote: > Extend the Maptrack comment to point at the Grant table subsystem. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] common/vcpu: Switch v->vcpu_info_mfn to mfn_t
>>> On 15.02.17 at 18:39, wrote: > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] xen/include: Remove explicit xen/config.h includes
>>> On 15.02.17 at 19:10, wrote: > This file is included automatically via CFLAGS. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] xen/include: Include xen/kconfig.h automatically
>>> On 15.02.17 at 19:10, wrote: > generated/autoconf.h is already included automatically so CONFIG_* defines are > avaialble. However, the companion macros such as IS_ENABLED() are not > included. > > Include them uniformally everywhere. Well, if you really think this is a good idea, I'm not going to stand in the way, but why do we need this included everywhere? Many files don't even care about any CONFIG_*, and hence even less so about kconfig.h. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] backport of "x86/hvm: don't rely on shared ioreq state for completion handling" ?
> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 16 February 2017 10:23 > To: Paul Durrant > Cc: xen-devel > Subject: RE: backport of "x86/hvm: don't rely on shared ioreq state for > completion handling" ? > > >>> On 16.02.17 at 11:13, wrote: > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: 16 February 2017 09:21 > >> > >> as it looks to be quite non-trivial an operation, did you happen to > >> have to backport commit 480b83162a to 4.4 or older, without > >> backporting all the ioreq server stuff at the same time? It looks to > >> me as if the issue predates the addition of ioreq servers, and us > >> having had customer reports here would seem to make this a > >> candidate fix (perhaps with at least 125833f5f1 ["x86: fix > >> ioreq-server event channel vulnerability"] also backported, which > >> also appears to address a pre-existing issue). > > > > Sorry, no I don't have a back-port. Agreed that the issue existed prior to > > ioreq servers but the checking was probably sufficiently lax that it never > > resulted in a domain_crash(), just bad data coming back from an emulation > > request. > > Well, according to the reports we've got, maybe it was less likely > to trigger, but it looks like it wasn't lax enough. Albeit I'm yet to > get confirmation that the issue was only seen during domain > shutdown, which aiui was (leaving aside a guest fiddling with the > shared structure, in which case it deserves being crashed) the > only condition triggering that domain_crash(). If it is only on shutdown then that's probably just a toolstack race (since QEMU should really by dying cleanly when the guest goes to S5) unless we're talking about a forced shutdown. > > Once I have aforementioned confirmation, would you mind if I > asked you to look over the backports, should I manage to create > them in the first place? > Sure. No problem. Paul > Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/multicall: Use the common hcall_preempted boolean
>>> On 15.02.17 at 20:41, wrote: > The now-common hcall_preempted boolean is perfectly usable for multicalls. Something must have gone in the wrong order here: This is not part of a series, and I can't see hcall_preempted being common in staging. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] xen/include: Include xen/kconfig.h automatically
On 16/02/17 10:27, Jan Beulich wrote: On 15.02.17 at 19:10, wrote: >> generated/autoconf.h is already included automatically so CONFIG_* defines >> are >> avaialble. However, the companion macros such as IS_ENABLED() are not >> included. >> >> Include them uniformally everywhere. > Well, if you really think this is a good idea, I'm not going to stand in > the way, but why do we need this included everywhere? Many files > don't even care about any CONFIG_*, and hence even less so about > kconfig.h. I am sorry, but you are complaining if I include it unilaterally, and also complaining if I include kconfig.h in the specific location where I need it. These are mutually exclusive. I do prefer this approach, overall. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/multicall: Use the common hcall_preempted boolean
On 16/02/17 10:37, Jan Beulich wrote: On 15.02.17 at 20:41, wrote: >> The now-common hcall_preempted boolean is perfectly usable for multicalls. > Something must have gone in the wrong order here: This is not part > of a series, and I can't see hcall_preempted being common in > staging. Sorry. I fumbled `git format-patch` and omitted the patch numbers. The correct order of the series is: Andrew Cooper (7): x86/hypercall: Make the HVM hcall_preempted boolean common arm/hypercall: Use the common hcall_preempted boolean xen/multicall: Use the common hcall_preempted boolean x86/hypercall: Make the HVM hcall_64bit boolean common x86/hypercall: Split out PV hypercall infrastructure x86/hypercall: Move hypercall continuation logic [RFC] x86/kconfig: Introduce CONFIG_PV and CONFIG_HVM ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/7] x86/hypercall: Make the HVM hcall_preempted boolean common
>>> On 15.02.17 at 20:41, wrote: > --- a/xen/include/xen/sched.h > +++ b/xen/include/xen/sched.h > @@ -202,6 +202,8 @@ struct vcpu > bool paused_for_shutdown; > /* VCPU need affinity restored */ > bool affinity_broken; > +/* A hypercall has been preempted. */ > +bool hcall_preempted; > > > /* Would you mind moving this addition between the two existing blank lines, so that together with the later movement here of hcall_64bit the two appear as a proper pair? With that Reviewed-by: Jan Beulich Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] backport of "x86/hvm: don't rely on shared ioreq state for completion handling" ?
>>> On 16.02.17 at 11:36, wrote: >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 16 February 2017 10:23 >> To: Paul Durrant >> Cc: xen-devel >> Subject: RE: backport of "x86/hvm: don't rely on shared ioreq state for >> completion handling" ? >> >> >>> On 16.02.17 at 11:13, wrote: >> >> From: Jan Beulich [mailto:jbeul...@suse.com] >> >> Sent: 16 February 2017 09:21 >> >> >> >> as it looks to be quite non-trivial an operation, did you happen to >> >> have to backport commit 480b83162a to 4.4 or older, without >> >> backporting all the ioreq server stuff at the same time? It looks to >> >> me as if the issue predates the addition of ioreq servers, and us >> >> having had customer reports here would seem to make this a >> >> candidate fix (perhaps with at least 125833f5f1 ["x86: fix >> >> ioreq-server event channel vulnerability"] also backported, which >> >> also appears to address a pre-existing issue). >> > >> > Sorry, no I don't have a back-port. Agreed that the issue existed prior to >> > ioreq servers but the checking was probably sufficiently lax that it never >> > resulted in a domain_crash(), just bad data coming back from an emulation >> > request. >> >> Well, according to the reports we've got, maybe it was less likely >> to trigger, but it looks like it wasn't lax enough. Albeit I'm yet to >> get confirmation that the issue was only seen during domain >> shutdown, which aiui was (leaving aside a guest fiddling with the >> shared structure, in which case it deserves being crashed) the >> only condition triggering that domain_crash(). > > If it is only on shutdown then that's probably just a toolstack race (since > QEMU should really by dying cleanly when the guest goes to S5) unless we're > talking about a forced shutdown. Then I may have misunderstood the original mail thread: Under what other conditions did this trigger for the original reporters (Sander and Roger)? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] xen/include: Include xen/kconfig.h automatically
>>> On 16.02.17 at 11:40, wrote: > On 16/02/17 10:27, Jan Beulich wrote: > On 15.02.17 at 19:10, wrote: >>> generated/autoconf.h is already included automatically so CONFIG_* defines >>> are >>> avaialble. However, the companion macros such as IS_ENABLED() are not >>> included. >>> >>> Include them uniformally everywhere. >> Well, if you really think this is a good idea, I'm not going to stand in >> the way, but why do we need this included everywhere? Many files >> don't even care about any CONFIG_*, and hence even less so about >> kconfig.h. > > I am sorry, but you are complaining if I include it unilaterally, and > also complaining if I include kconfig.h in the specific location where I > need it. These are mutually exclusive. I don't understand - when did I complain about its inclusion where it's needed? Iirc my complaint was about you adding the inclusion to */config.h without that header actually using the macros. My point really is that ideally each C file would get as little cruft as possible, while at present quite a number of header are being included by virtually every source file. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] backport of "x86/hvm: don't rely on shared ioreq state for completion handling" ?
> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 16 February 2017 10:46 > To: Paul Durrant > Cc: xen-devel > Subject: RE: backport of "x86/hvm: don't rely on shared ioreq state for > completion handling" ? > > >>> On 16.02.17 at 11:36, wrote: > >> -Original Message- > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: 16 February 2017 10:23 > >> To: Paul Durrant > >> Cc: xen-devel > >> Subject: RE: backport of "x86/hvm: don't rely on shared ioreq state for > >> completion handling" ? > >> > >> >>> On 16.02.17 at 11:13, wrote: > >> >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> >> Sent: 16 February 2017 09:21 > >> >> > >> >> as it looks to be quite non-trivial an operation, did you happen to > >> >> have to backport commit 480b83162a to 4.4 or older, without > >> >> backporting all the ioreq server stuff at the same time? It looks to > >> >> me as if the issue predates the addition of ioreq servers, and us > >> >> having had customer reports here would seem to make this a > >> >> candidate fix (perhaps with at least 125833f5f1 ["x86: fix > >> >> ioreq-server event channel vulnerability"] also backported, which > >> >> also appears to address a pre-existing issue). > >> > > >> > Sorry, no I don't have a back-port. Agreed that the issue existed prior > >> > to > >> > ioreq servers but the checking was probably sufficiently lax that it > >> > never > >> > resulted in a domain_crash(), just bad data coming back from an > emulation > >> > request. > >> > >> Well, according to the reports we've got, maybe it was less likely > >> to trigger, but it looks like it wasn't lax enough. Albeit I'm yet to > >> get confirmation that the issue was only seen during domain > >> shutdown, which aiui was (leaving aside a guest fiddling with the > >> shared structure, in which case it deserves being crashed) the > >> only condition triggering that domain_crash(). > > > > If it is only on shutdown then that's probably just a toolstack race (since > > QEMU should really by dying cleanly when the guest goes to S5) unless > we're > > talking about a forced shutdown. > > Then I may have misunderstood the original mail thread: Under > what other conditions did this trigger for the original reporters > (Sander and Roger)? Now you're asking... I'll have to see if I can find the original mail threads. It's possible it was stubdom related... but I could be thinking of something else. Paul > > Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 105824: regressions - FAIL
flight 105824 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/105824/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-libvirt 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 59254 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail in 105795 pass in 105824 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail pass in 105795 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-rtds 9 debian-installfail REGR. vs. 59254 test-armhf-armhf-libvirt-raw 6 xen-bootfail baseline untested test-armhf-armhf-xl-vhd 6 xen-bootfail baseline untested test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass build-arm64-xsm 5 xen-buildfail never pass build-arm64 5 xen-buildfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 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-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass version targeted for testing: linux747ae0a96f1a78b35c5a3d93ad37a16655e16340 baseline version: linux45820c294fe1b1a9df495d57f40585ef2d069a39 Last test of basis59254 2015-07-09 04:20:48 Z 588 days Failing since 59348 2015-07-10 04:24:05 Z 587 days 277 attempts Testing same since 105795 2017-02-14 15:48:07 Z1 days4 attempts 7580 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 fail build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt blocked build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvops
Re: [Xen-devel] backport of "x86/hvm: don't rely on shared ioreq state for completion handling" ?
>>> On 16.02.17 at 11:53, wrote: >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 16 February 2017 10:46 >> To: Paul Durrant >> Cc: xen-devel >> Subject: RE: backport of "x86/hvm: don't rely on shared ioreq state for >> completion handling" ? >> >> >>> On 16.02.17 at 11:36, wrote: >> >> -Original Message- >> >> From: Jan Beulich [mailto:jbeul...@suse.com] >> >> Sent: 16 February 2017 10:23 >> >> To: Paul Durrant >> >> Cc: xen-devel >> >> Subject: RE: backport of "x86/hvm: don't rely on shared ioreq state for >> >> completion handling" ? >> >> >> >> >>> On 16.02.17 at 11:13, wrote: >> >> >> From: Jan Beulich [mailto:jbeul...@suse.com] >> >> >> Sent: 16 February 2017 09:21 >> >> >> >> >> >> as it looks to be quite non-trivial an operation, did you happen to >> >> >> have to backport commit 480b83162a to 4.4 or older, without >> >> >> backporting all the ioreq server stuff at the same time? It looks to >> >> >> me as if the issue predates the addition of ioreq servers, and us >> >> >> having had customer reports here would seem to make this a >> >> >> candidate fix (perhaps with at least 125833f5f1 ["x86: fix >> >> >> ioreq-server event channel vulnerability"] also backported, which >> >> >> also appears to address a pre-existing issue). >> >> > >> >> > Sorry, no I don't have a back-port. Agreed that the issue existed prior >> >> > to >> >> > ioreq servers but the checking was probably sufficiently lax that it >> >> > never >> >> > resulted in a domain_crash(), just bad data coming back from an >> emulation >> >> > request. >> >> >> >> Well, according to the reports we've got, maybe it was less likely >> >> to trigger, but it looks like it wasn't lax enough. Albeit I'm yet to >> >> get confirmation that the issue was only seen during domain >> >> shutdown, which aiui was (leaving aside a guest fiddling with the >> >> shared structure, in which case it deserves being crashed) the >> >> only condition triggering that domain_crash(). >> > >> > If it is only on shutdown then that's probably just a toolstack race (since >> > QEMU should really by dying cleanly when the guest goes to S5) unless >> we're >> > talking about a forced shutdown. >> >> Then I may have misunderstood the original mail thread: Under >> what other conditions did this trigger for the original reporters >> (Sander and Roger)? > > Now you're asking... I'll have to see if I can find the original mail > threads. It's possible it was stubdom related... but I could be thinking of > something else. https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg05210.html Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] xen/include: Include xen/kconfig.h automatically
On 16/02/17 10:48, Jan Beulich wrote: On 16.02.17 at 11:40, wrote: >> On 16/02/17 10:27, Jan Beulich wrote: >> On 15.02.17 at 19:10, wrote: generated/autoconf.h is already included automatically so CONFIG_* defines are avaialble. However, the companion macros such as IS_ENABLED() are not included. Include them uniformally everywhere. >>> Well, if you really think this is a good idea, I'm not going to stand in >>> the way, but why do we need this included everywhere? Many files >>> don't even care about any CONFIG_*, and hence even less so about >>> kconfig.h. >> I am sorry, but you are complaining if I include it unilaterally, and >> also complaining if I include kconfig.h in the specific location where I >> need it. These are mutually exclusive. > I don't understand - when did I complain about its inclusion where > it's needed? Iirc my complaint was about you adding the inclusion > to */config.h without that header actually using the macros. My > point really is that ideally each C file would get as little cruft as > possible, while at present quite a number of header are being > included by virtually every source file. Your complaint was specifically about me adding it to paging.h so I could use IS_ENABLED() and not out-of-line a trivial function. As for general availably, while I agree in general that we have far too much stuff included by default (I have some plans for that), the contents of kconfig.h is fairly small, and exactly the same category of information as config.h I am looking to push for the use of IS_ENABLED() in preference to #ifdef where possible, to reduce code-rot. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/7] xen/multicall: Use the common hcall_preempted boolean
>>> On 15.02.17 at 20:41, wrote: > The now-common hcall_preempted boolean is perfectly usable for multicalls. > Remove the multicall-specific preemption mechanism. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/7] x86/hypercall: Make the HVM hcall_64bit boolean common
>>> On 15.02.17 at 20:41, wrote: > HVM guests currently make use of arch.hvm_vcpu.hcall_64bit to track the ABI of > the hypercall in use. > > The rest of Xen deals in terms of the comat ABI or not, so rename the boolean > and make it common, guared by CONFIG_COMPAT to avoid bloat if a compat ABI is > not wanted/needed. > > Set hcall_compat uniformly for PV guests as well as HVM guests. This removes > the remaining piece of guest-type-specific knowledge from > hypercall_create_continuation(), allowing it to operate only in terms of the > hypercall ABI in use. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] xen/include: Include xen/kconfig.h automatically
>>> On 16.02.17 at 12:01, wrote: > On 16/02/17 10:48, Jan Beulich wrote: > On 16.02.17 at 11:40, wrote: >>> On 16/02/17 10:27, Jan Beulich wrote: >>> On 15.02.17 at 19:10, wrote: > generated/autoconf.h is already included automatically so CONFIG_* > defines > are > avaialble. However, the companion macros such as IS_ENABLED() are not > included. > > Include them uniformally everywhere. Well, if you really think this is a good idea, I'm not going to stand in the way, but why do we need this included everywhere? Many files don't even care about any CONFIG_*, and hence even less so about kconfig.h. >>> I am sorry, but you are complaining if I include it unilaterally, and >>> also complaining if I include kconfig.h in the specific location where I >>> need it. These are mutually exclusive. >> I don't understand - when did I complain about its inclusion where >> it's needed? Iirc my complaint was about you adding the inclusion >> to */config.h without that header actually using the macros. My >> point really is that ideally each C file would get as little cruft as >> possible, while at present quite a number of header are being >> included by virtually every source file. > > Your complaint was specifically about me adding it to paging.h so I > could use IS_ENABLED() and not out-of-line a trivial function. Oh, that one: There my view was the other way around: No need to include yet another header in one which already gets included everywhere, when the new function could easily be out of line (as not being performance critical). > As for general availably, while I agree in general that we have far too > much stuff included by default (I have some plans for that), the > contents of kconfig.h is fairly small, and exactly the same category of > information as config.h > > I am looking to push for the use of IS_ENABLED() in preference to #ifdef > where possible, to reduce code-rot. Which makes sense, but won't affect said source files not using any CONFIG_* in the first place. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 0/2] x86: context switch handling adjustments
1: VMX: fix VMCS race on context-switch paths 2: x86: package up context switch hook pointers Signed-off-by: Jan Beulich --- v2: Several changes to patch 1 (see there) requiring adjustment to patch 2 (again, see there). ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling
>>> On 15.02.17 at 12:21, wrote: > At 01:18 -0700 on 15 Feb (1487121525), Jan Beulich wrote: >> >>> On 14.02.17 at 18:33, wrote: >> >> TBD: Do we really want to re-init the TSS every time we are about to >> >> use it? >> > >> > No - I think we should init it when the guest writes the param(s) and >> > leave it at that. Hvmloader marks it as reserved so the guest should >> > know better than to write to it, and we can't protect it against all >> > the possible ways the guest could break itself. >> > >> > If you do want to re-init it more often, then I think it would still >> > be better to legacy guests' (lack of a) size limit once, when the guest >> > writes the base param. >> >> The only problem with this being that at the time the base gets >> written we don't know the size yet (nor whether the guest is >> going to write it), and hence we don't know how must space to >> initialize. The lower limit we enforce on the size (if being set) is >> below the 128 byte default for old guests. > > Why not make the lower limit 128? I'd happily exchange simpler > hypervisor code for the theoretical case of a guest that needs to run > realmode code and cares about those few bytes. Actually there's one more issue with doing it when the parameter is being set: If a guest wanted to move the TSS (the parameter isn't one-shot after all), we can't use the old value of the other parameter when the first of the two is being changed. Of course we could make both parameters one-shot, but this would again seem arbitrary. So I think the better model is to record when either parameter changed, and do the initialization just once after that. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 1/2] VMX: fix VMCS race on context-switch paths
When __context_switch() is being bypassed during original context
switch handling, the vCPU "owning" the VMCS partially loses control of
it: It will appear non-running to remote CPUs, and hence their attempt
to pause the owning vCPU will have no effect on it (as it already
looks to be paused). At the same time the "owning" CPU will re-enable
interrupts eventually (the lastest when entering the idle loop) and
hence becomes subject to IPIs from other CPUs requesting access to the
VMCS. As a result, when __context_switch() finally gets run, the CPU
may no longer have the VMCS loaded, and hence any accesses to it would
fail. Hence we may need to re-load the VMCS in vmx_ctxt_switch_from().
Similarly, when __context_switch() is being bypassed also on the second
(switch-in) path, VMCS ownership may have been lost and hence needs
re-establishing. Since there's no existing hook to put this in, add a
new one.
Reported-by: Kevin Mayer
Reported-by: Anshul Makkar
Signed-off-by: Jan Beulich
---
v2: Drop the spin loop from vmx_vmc_reload(). Use the function in
vmx_do_resume() instead of open coding it there (requiring the
ASSERT()s to be adjusted/dropped). Drop the new
->ctxt_switch_same() hook.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -552,6 +552,20 @@ static void vmx_load_vmcs(struct vcpu *v
local_irq_restore(flags);
}
+void vmx_vmcs_reload(struct vcpu *v)
+{
+/*
+ * As we may be running with interrupts disabled, we can't acquire
+ * v->arch.hvm_vmx.vmcs_lock here. However, with interrupts disabled
+ * the VMCS can't be taken away from us anymore if we still own it.
+ */
+ASSERT(v->is_running || !local_irq_is_enabled());
+if ( v->arch.hvm_vmx.vmcs_pa == this_cpu(current_vmcs) )
+return;
+
+vmx_load_vmcs(v);
+}
+
int vmx_cpu_up_prepare(unsigned int cpu)
{
/*
@@ -1678,10 +1692,7 @@ void vmx_do_resume(struct vcpu *v)
bool_t debug_state;
if ( v->arch.hvm_vmx.active_cpu == smp_processor_id() )
-{
-if ( v->arch.hvm_vmx.vmcs_pa != this_cpu(current_vmcs) )
-vmx_load_vmcs(v);
-}
+vmx_vmcs_reload(v);
else
{
/*
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -936,6 +937,18 @@ static void vmx_ctxt_switch_from(struct
if ( unlikely(!this_cpu(vmxon)) )
return;
+if ( !v->is_running )
+{
+/*
+ * When this vCPU isn't marked as running anymore, a remote pCPU's
+ * attempt to pause us (from vmx_vmcs_enter()) won't have a reason
+ * to spin in vcpu_sleep_sync(), and hence that pCPU might have taken
+ * away the VMCS from us. As we're running with interrupts disabled,
+ * we also can't call vmx_vmcs_enter().
+ */
+vmx_vmcs_reload(v);
+}
+
vmx_fpu_leave(v);
vmx_save_guest_msrs(v);
vmx_restore_host_msrs();
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -174,6 +174,7 @@ void vmx_destroy_vmcs(struct vcpu *v);
void vmx_vmcs_enter(struct vcpu *v);
bool_t __must_check vmx_vmcs_try_enter(struct vcpu *v);
void vmx_vmcs_exit(struct vcpu *v);
+void vmx_vmcs_reload(struct vcpu *v);
#define CPU_BASED_VIRTUAL_INTR_PENDING0x0004
#define CPU_BASED_USE_TSC_OFFSETING 0x0008
VMX: fix VMCS race on context-switch paths
When __context_switch() is being bypassed during original context
switch handling, the vCPU "owning" the VMCS partially loses control of
it: It will appear non-running to remote CPUs, and hence their attempt
to pause the owning vCPU will have no effect on it (as it already
looks to be paused). At the same time the "owning" CPU will re-enable
interrupts eventually (the lastest when entering the idle loop) and
hence becomes subject to IPIs from other CPUs requesting access to the
VMCS. As a result, when __context_switch() finally gets run, the CPU
may no longer have the VMCS loaded, and hence any accesses to it would
fail. Hence we may need to re-load the VMCS in vmx_ctxt_switch_from().
Similarly, when __context_switch() is being bypassed also on the second
(switch-in) path, VMCS ownership may have been lost and hence needs
re-establishing. Since there's no existing hook to put this in, add a
new one.
Reported-by: Kevin Mayer
Reported-by: Anshul Makkar
Signed-off-by: Jan Beulich
---
v2: Drop the spin loop from vmx_vmc_reload(). Use the function in
vmx_do_resume() instead of open coding it there (requiring the
ASSERT()s to be adjusted/dropped). Drop the new
->ctxt_switch_same() hook.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -552,6 +552,20 @@ static void vmx_load_vmcs(struct vcpu *v
local_irq_restore(flags);
}
+void vmx_vmcs_reload(struct vcpu *v)
+{
+/*
+ * As we may be running with interrupts disabled, we can't acquire
+ * v->arch.hvm_vmx.vmcs_lock here. However, with interrupts disabled
+ * the VMCS can't be ta
[Xen-devel] [PATCH v2 2/2] x86: package up context switch hook pointers
They're all solely dependent on guest type, so we don't need to repeat
all the same three pointers in every vCPU control structure. Instead use
static const structures, and store pointers to them in the domain
control structure.
Since touching it anyway, take the opportunity and expand
schedule_tail() in the only two places invoking it, allowing the macro
to be dropped.
Signed-off-by: Jan Beulich
Reviewed-by: Boris Ostrovsky
---
v2: Drop the schedule_tail() macro altogether. Re-base after dropped
->ctxt_switch_same() hook.
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -426,16 +426,8 @@ int vcpu_initialise(struct vcpu *v)
/* PV guests by default have a 100Hz ticker. */
v->periodic_period = MILLISECS(10);
}
-
-v->arch.schedule_tail = continue_nonidle_domain;
-v->arch.ctxt_switch_from = paravirt_ctxt_switch_from;
-v->arch.ctxt_switch_to = paravirt_ctxt_switch_to;
-
-if ( is_idle_domain(d) )
-{
-v->arch.schedule_tail = continue_idle_domain;
-v->arch.cr3 = __pa(idle_pg_table);
-}
+else
+v->arch.cr3 = __pa(idle_pg_table);
v->arch.pv_vcpu.ctrlreg[4] = real_cr4_to_pv_guest_cr4(mmu_cr4_features);
@@ -642,8 +634,23 @@ int arch_domain_create(struct domain *d,
goto fail;
}
else
+{
+static const struct arch_csw pv_csw = {
+.from = paravirt_ctxt_switch_from,
+.to = paravirt_ctxt_switch_to,
+.tail = continue_nonidle_domain,
+};
+static const struct arch_csw idle_csw = {
+.from = paravirt_ctxt_switch_from,
+.to = paravirt_ctxt_switch_to,
+.tail = continue_idle_domain,
+};
+
+d->arch.ctxt_switch = is_idle_domain(d) ? &idle_csw : &pv_csw;
+
/* 64-bit PV guest by default. */
d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
+}
/* initialize default tsc behavior in case tools don't */
tsc_set_info(d, TSC_MODE_DEFAULT, 0UL, 0, 0);
@@ -1997,7 +2004,7 @@ static void __context_switch(void)
{
memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
vcpu_save_fpu(p);
-p->arch.ctxt_switch_from(p);
+pd->arch.ctxt_switch->from(p);
}
/*
@@ -2023,7 +2030,7 @@ static void __context_switch(void)
set_msr_xss(n->arch.hvm_vcpu.msr_xss);
}
vcpu_restore_fpu_eager(n);
-n->arch.ctxt_switch_to(n);
+nd->arch.ctxt_switch->to(n);
}
psr_ctxt_switch_to(nd);
@@ -2142,12 +2149,20 @@ void context_switch(struct vcpu *prev, s
/* Ensure that the vcpu has an up-to-date time base. */
update_vcpu_system_time(next);
-schedule_tail(next);
+/*
+ * Schedule tail *should* be a terminal function pointer, but leave a
+ * bug frame around just in case it returns, to save going back into the
+ * context switching code and leaving a far more subtle crash to diagnose.
+ */
+nextd->arch.ctxt_switch->tail(next);
+BUG();
}
void continue_running(struct vcpu *same)
{
-schedule_tail(same);
+/* See the comment above. */
+same->domain->arch.ctxt_switch->tail(same);
+BUG();
}
int __sync_local_execstate(void)
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1144,6 +1144,14 @@ void svm_host_osvw_init()
static int svm_domain_initialise(struct domain *d)
{
+static const struct arch_csw csw = {
+.from = svm_ctxt_switch_from,
+.to = svm_ctxt_switch_to,
+.tail = svm_do_resume,
+};
+
+d->arch.ctxt_switch = &csw;
+
return 0;
}
@@ -1155,10 +1163,6 @@ static int svm_vcpu_initialise(struct vc
{
int rc;
-v->arch.schedule_tail= svm_do_resume;
-v->arch.ctxt_switch_from = svm_ctxt_switch_from;
-v->arch.ctxt_switch_to = svm_ctxt_switch_to;
-
v->arch.hvm_svm.launch_core = -1;
if ( (rc = svm_create_vmcb(v)) != 0 )
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -268,8 +268,15 @@ void vmx_pi_hooks_deassign(struct domain
static int vmx_domain_initialise(struct domain *d)
{
+static const struct arch_csw csw = {
+.from = vmx_ctxt_switch_from,
+.to = vmx_ctxt_switch_to,
+.tail = vmx_do_resume,
+};
int rc;
+d->arch.ctxt_switch = &csw;
+
if ( !has_vlapic(d) )
return 0;
@@ -295,10 +302,6 @@ static int vmx_vcpu_initialise(struct vc
INIT_LIST_HEAD(&v->arch.hvm_vmx.pi_blocking.list);
-v->arch.schedule_tail= vmx_do_resume;
-v->arch.ctxt_switch_from = vmx_ctxt_switch_from;
-v->arch.ctxt_switch_to = vmx_ctxt_switch_to;
-
if ( (rc = vmx_create_vmcs(v)) != 0 )
{
dprintk(XENLOG_WARNING,
--- a/xen/include/asm-x86/current.h
+++ b/xen/include/asm-x86/current.h
@@ -103,16 +103,6 @@ unsigned long get_stack_dump_bottom (uns
})
/*
- * Schedule tail *should* be a terminal function pointer, but leave
Re: [Xen-devel] backport of "x86/hvm: don't rely on shared ioreq state for completion handling" ?
> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 16 February 2017 11:00 > To: Paul Durrant > Cc: xen-devel > Subject: RE: backport of "x86/hvm: don't rely on shared ioreq state for > completion handling" ? > > >>> On 16.02.17 at 11:53, wrote: > >> -Original Message- > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: 16 February 2017 10:46 > >> To: Paul Durrant > >> Cc: xen-devel > >> Subject: RE: backport of "x86/hvm: don't rely on shared ioreq state for > >> completion handling" ? > >> > >> >>> On 16.02.17 at 11:36, wrote: > >> >> -Original Message- > >> >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> >> Sent: 16 February 2017 10:23 > >> >> To: Paul Durrant > >> >> Cc: xen-devel > >> >> Subject: RE: backport of "x86/hvm: don't rely on shared ioreq state for > >> >> completion handling" ? > >> >> > >> >> >>> On 16.02.17 at 11:13, wrote: > >> >> >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> >> >> Sent: 16 February 2017 09:21 > >> >> >> > >> >> >> as it looks to be quite non-trivial an operation, did you happen to > >> >> >> have to backport commit 480b83162a to 4.4 or older, without > >> >> >> backporting all the ioreq server stuff at the same time? It looks to > >> >> >> me as if the issue predates the addition of ioreq servers, and us > >> >> >> having had customer reports here would seem to make this a > >> >> >> candidate fix (perhaps with at least 125833f5f1 ["x86: fix > >> >> >> ioreq-server event channel vulnerability"] also backported, which > >> >> >> also appears to address a pre-existing issue). > >> >> > > >> >> > Sorry, no I don't have a back-port. Agreed that the issue existed > >> >> > prior > to > >> >> > ioreq servers but the checking was probably sufficiently lax that it > never > >> >> > resulted in a domain_crash(), just bad data coming back from an > >> emulation > >> >> > request. > >> >> > >> >> Well, according to the reports we've got, maybe it was less likely > >> >> to trigger, but it looks like it wasn't lax enough. Albeit I'm yet to > >> >> get confirmation that the issue was only seen during domain > >> >> shutdown, which aiui was (leaving aside a guest fiddling with the > >> >> shared structure, in which case it deserves being crashed) the > >> >> only condition triggering that domain_crash(). > >> > > >> > If it is only on shutdown then that's probably just a toolstack race > >> > (since > >> > QEMU should really by dying cleanly when the guest goes to S5) unless > >> we're > >> > talking about a forced shutdown. > >> > >> Then I may have misunderstood the original mail thread: Under > >> what other conditions did this trigger for the original reporters > >> (Sander and Roger)? > > > > Now you're asking... I'll have to see if I can find the original mail > > threads. It's possible it was stubdom related... but I could be thinking of > > something else. > > https://lists.xenproject.org/archives/html/xen-devel/2015- > 07/msg05210.html > Thanks. So, looking at my message https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg05506.html, the problem with the emulator/toolstack was never diagnosed. I wonder whether it is a problem with running a PV aware guest in an HVM container, and using a PV shutdown mechanism causing the toolstack to kill the emulator rather than it shutting down gracefully? Prior to the ioreq series going in, the shared ioreq pages were never removed from the P2M, and so there was no concept of zeroing them before re-insertion (resulting in the ioreq state magically going straight to 'none' rather than 'resp ready'). Hence, even if the emulator were killed, you wouldn't hit the same sort of crash... more likely you'd end up with a stuck emulation and a wedged vcpu. Roger's repro was with FreeBSD which is quite PV aware AFAIK. All my prior testing was done with Windows. So, maybe this points at a problem with libxl's behaviour when a guest is shutting down? Paul > Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen
2016-11-11 04:49, Tan, Jianfeng: > Hi Thomas and Konrad, > > On 11/11/2016 2:59 AM, Konrad Rzeszutek Wilk wrote: > > On Wed, Nov 9, 2016 at 5:03 PM, Thomas Monjalon wrote: > >> 2016-11-07 07:38, Jianfeng Tan: > >>> As some users are still using xen as the hypervisor, I suggest to > >>> continue support for xen in DPDK. And from 16.11, I will be the > >>> maintainer of all xen-related files. > >>> > >>> Signed-off-by: Jianfeng Tan > >> Applied > >> > >> Please Jianfeng, could you start your new role by sending a status > >> of Xen dom0 support in DPDK? I think there are some issues in latest > >> releases. > > Yes, I'm on this. And hope to send out update in the next week. > > > Pls also CC me and xen-de...@lists.xenproject.org if possible. > > Glad to do that. > > Thanks, > Jianfeng Any news about Xen dom0 status in DPDK? I think there is not enough interest for Xen dom0 in the DPDK community. Last time we talked about, it was because of a severe bug which is not fixed yet: http://dpdk.org/ml/archives/dev/2016-July/044207.html http://dpdk.org/ml/archives/dev/2016-July/044376.html The request (6 month ago) was to give more time for feedbacks: http://dpdk.org/ml/archives/dev/2016-July/044847.html Is it time now to officially remove Dom0 support? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/hypercall: Split out PV hypercall infrastructure
>>> On 15.02.17 at 20:41, wrote: > --- a/xen/arch/x86/hypercall.c > +++ b/xen/arch/x86/pv/hypercall.c > @@ -1,5 +1,7 @@ > /** > - * arch/x86/hypercall.c > + * arch/pv/hypercall.c arch/x86/pv/hypercall.c (if we really need files to name themselves) Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] backport of "x86/hvm: don't rely on shared ioreq state for completion handling" ?
>>> On 16.02.17 at 12:17, wrote: > Roger's repro was with FreeBSD which is quite PV aware AFAIK. All my prior > testing was done with Windows. So, maybe this points at a problem with > libxl's behaviour when a guest is shutting down? Not impossible, but with what you say I will want to be even more certain that the reports we have are for guests being shut down, so I'll definitely want to wait with any backporting attempt. Thanks for the additional insight in any event! Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/hypercall: Move hypercall continuation logic
>>> On 15.02.17 at 20:41, wrote: > The newly-repurposed arch/x86/hypercall.c is a more appropriate place for the > hypercall continuation logic to live. > > This is purely code motion. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86: package up context switch hook pointers
On 16/02/17 11:16, Jan Beulich wrote: > They're all solely dependent on guest type, so we don't need to repeat > all the same three pointers in every vCPU control structure. Instead use > static const structures, and store pointers to them in the domain > control structure. > > Since touching it anyway, take the opportunity and expand > schedule_tail() in the only two places invoking it, allowing the macro > to be dropped. > > Signed-off-by: Jan Beulich > Reviewed-by: Boris Ostrovsky Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling
>>> On 16.02.17 at 12:14, wrote: On 15.02.17 at 12:21, wrote: >> At 01:18 -0700 on 15 Feb (1487121525), Jan Beulich wrote: >>> >>> On 14.02.17 at 18:33, wrote: >>> >> TBD: Do we really want to re-init the TSS every time we are about to >>> >> use it? >>> > >>> > No - I think we should init it when the guest writes the param(s) and >>> > leave it at that. Hvmloader marks it as reserved so the guest should >>> > know better than to write to it, and we can't protect it against all >>> > the possible ways the guest could break itself. >>> > >>> > If you do want to re-init it more often, then I think it would still >>> > be better to legacy guests' (lack of a) size limit once, when the guest >>> > writes the base param. >>> >>> The only problem with this being that at the time the base gets >>> written we don't know the size yet (nor whether the guest is >>> going to write it), and hence we don't know how must space to >>> initialize. The lower limit we enforce on the size (if being set) is >>> below the 128 byte default for old guests. >> >> Why not make the lower limit 128? I'd happily exchange simpler >> hypervisor code for the theoretical case of a guest that needs to run >> realmode code and cares about those few bytes. > > Actually there's one more issue with doing it when the parameter is > being set: If a guest wanted to move the TSS (the parameter isn't > one-shot after all), we can't use the old value of the other parameter > when the first of the two is being changed. Of course we could make > both parameters one-shot, but this would again seem arbitrary. So I > think the better model is to record when either parameter changed, > and do the initialization just once after that. Actually no, this wouldn't work either, for the same reason (we might again be using an inconsistent pair of parameters). Which makes me come back to my original plan (not mentioned anywhere so far): Instead of a new size param, we need one which allows setting both size and address at the same time. Since the address needs to be below 4Gb anyway, we could simply use the high half of the 64-bit value to hold the size. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.5-testing test] 105827: regressions - FAIL
flight 105827 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105827/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 104590 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl 7 host-ping-check-xenfail pass in 105817 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 105817 like 104573 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail in 105817 like 104590 test-amd64-amd64-xl-rtds 6 xen-boot fail like 104590 test-xtf-amd64-amd64-2 53 leak-check/check fail like 104590 test-xtf-amd64-amd64-3 53 leak-check/check fail like 104590 test-xtf-amd64-amd64-4 53 leak-check/check fail like 104590 test-xtf-amd64-amd64-5 53 leak-check/check fail like 104590 test-xtf-amd64-amd64-1 53 leak-check/check fail like 104590 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 104590 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104590 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104590 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 12 migrate-support-check fail in 105817 never pass test-armhf-armhf-xl 13 saverestore-support-check fail in 105817 never pass test-xtf-amd64-amd64-2 18 xtf/test-hvm32-cpuid-faulting fail never pass test-xtf-amd64-amd64-2 30 xtf/test-hvm32pae-cpuid-faulting fail never pass test-xtf-amd64-amd64-2 36 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-2 40 xtf/test-hvm64-cpuid-faulting fail never pass test-xtf-amd64-amd64-4 18 xtf/test-hvm32-cpuid-faulting fail never pass test-xtf-amd64-amd64-4 30 xtf/test-hvm32pae-cpuid-faulting fail never pass test-xtf-amd64-amd64-5 18 xtf/test-hvm32-cpuid-faulting fail never pass test-xtf-amd64-amd64-1 18 xtf/test-hvm32-cpuid-faulting fail never pass test-xtf-amd64-amd64-4 36 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-4 40 xtf/test-hvm64-cpuid-faulting fail never pass test-xtf-amd64-amd64-5 30 xtf/test-hvm32pae-cpuid-faulting fail never pass test-xtf-amd64-amd64-1 30 xtf/test-hvm32pae-cpuid-faulting fail never pass test-xtf-amd64-amd64-5 36 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-1 36 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-5 40 xtf/test-hvm64-cpuid-faulting fail never pass test-xtf-amd64-amd64-1 40 xtf/test-hvm64-cpuid-faulting fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-xtf-amd64-amd64-2 52 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-3 52 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-4 52 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-5 52 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-1 52 xtf/test-hvm64-xsa-195 fail 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-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 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-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 10 guest-start fail never pass test-armhf-armhf-libvirt-raw 10 guest-start fail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass version targeted for testing: xen 43d06efb724d32a70b1cc9973d7cdcbbb5d96105 baseline version: xen 2b17bf45470bf742d78a22116e3b7ec1a3213c45 Last test of basis 10459
Re: [Xen-devel] [PATCH 3/3] xen/include: Include xen/kconfig.h automatically
On 16/02/17 11:10, Jan Beulich wrote: On 16.02.17 at 12:01, wrote: >> On 16/02/17 10:48, Jan Beulich wrote: >> On 16.02.17 at 11:40, wrote: On 16/02/17 10:27, Jan Beulich wrote: On 15.02.17 at 19:10, wrote: >> generated/autoconf.h is already included automatically so CONFIG_* >> defines >> are >> avaialble. However, the companion macros such as IS_ENABLED() are not >> included. >> >> Include them uniformally everywhere. > Well, if you really think this is a good idea, I'm not going to stand in > the way, but why do we need this included everywhere? Many files > don't even care about any CONFIG_*, and hence even less so about > kconfig.h. I am sorry, but you are complaining if I include it unilaterally, and also complaining if I include kconfig.h in the specific location where I need it. These are mutually exclusive. >>> I don't understand - when did I complain about its inclusion where >>> it's needed? Iirc my complaint was about you adding the inclusion >>> to */config.h without that header actually using the macros. My >>> point really is that ideally each C file would get as little cruft as >>> possible, while at present quite a number of header are being >>> included by virtually every source file. >> Your complaint was specifically about me adding it to paging.h so I >> could use IS_ENABLED() and not out-of-line a trivial function. > Oh, that one: There my view was the other way around: No need > to include yet another header in one which already gets included > everywhere, when the new function could easily be out of line (as > not being performance critical). > >> As for general availably, while I agree in general that we have far too >> much stuff included by default (I have some plans for that), the >> contents of kconfig.h is fairly small, and exactly the same category of >> information as config.h >> >> I am looking to push for the use of IS_ENABLED() in preference to #ifdef >> where possible, to reduce code-rot. > Which makes sense, but won't affect said source files not using any > CONFIG_* in the first place. We already include CONFIG_* everywhere. All this change does is consistently add IS_ENABLED() alongside, so it can be used when CONFIG_* are available. If we have occasion in the future to reconsider having the CONFIG_* variables unilaterally included, then fine, but the current state of the code is the worst of all options. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] xen/include: Include xen/kconfig.h automatically
Hi Jan, On 16/02/17 11:10, Jan Beulich wrote: On 16.02.17 at 12:01, wrote: On 16/02/17 10:48, Jan Beulich wrote: On 16.02.17 at 11:40, wrote: On 16/02/17 10:27, Jan Beulich wrote: On 15.02.17 at 19:10, wrote: generated/autoconf.h is already included automatically so CONFIG_* defines are avaialble. However, the companion macros such as IS_ENABLED() are not included. Include them uniformally everywhere. Well, if you really think this is a good idea, I'm not going to stand in the way, but why do we need this included everywhere? Many files don't even care about any CONFIG_*, and hence even less so about kconfig.h. I am sorry, but you are complaining if I include it unilaterally, and also complaining if I include kconfig.h in the specific location where I need it. These are mutually exclusive. I don't understand - when did I complain about its inclusion where it's needed? Iirc my complaint was about you adding the inclusion to */config.h without that header actually using the macros. My point really is that ideally each C file would get as little cruft as possible, while at present quite a number of header are being included by virtually every source file. Your complaint was specifically about me adding it to paging.h so I could use IS_ENABLED() and not out-of-line a trivial function. Oh, that one: There my view was the other way around: No need to include yet another header in one which already gets included everywhere, when the new function could easily be out of line (as not being performance critical). As for general availably, while I agree in general that we have far too much stuff included by default (I have some plans for that), the contents of kconfig.h is fairly small, and exactly the same category of information as config.h I am looking to push for the use of IS_ENABLED() in preference to #ifdef where possible, to reduce code-rot. Which makes sense, but won't affect said source files not using any CONFIG_* in the first place. At least on ARM, we need CONFIG_* everywhere as the definitions of types and structure will change whether you are compiling for ARM64 or ARM. I would expect the same for common code. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [RFC 3/6] Drop rangeset_domain_initialise()
From: Andrii Anisov
The rangeset_domain_initialise() does nothing rangeset specific.
Even keeping it specific to domain looks not reasonable. So drop it.
Signed-off-by: Andrii Anisov
---
xen/common/domain.c| 3 ++-
xen/common/rangeset.c | 7 ---
xen/include/xen/rangeset.h | 4 +---
3 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index f03a032..7fe69c6 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -326,7 +326,8 @@ struct domain *domain_create(domid_t domid, unsigned int
domcr_flags,
d->disable_migrate = 1;
}
-rangeset_domain_initialise(d);
+INIT_LIST_HEAD(&d->rangesets);
+spin_lock_init(&d->rangesets_lock);
init_status |= INIT_rangeset;
d->iomem_caps = domain_rangeset_new(d, "I/O Memory",
RANGESETF_prettyprint_hex);
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index 1172950..1a13a32 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -381,13 +381,6 @@ void rangeset_limit(
r->nr_ranges = limit;
}
-void rangeset_domain_initialise(
-struct domain *d)
-{
-INIT_LIST_HEAD(&d->rangesets);
-spin_lock_init(&d->rangesets_lock);
-}
-
void rangeset_domain_destroy(
struct domain *d)
{
diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
index deed54d..e8244a0 100644
--- a/xen/include/xen/rangeset.h
+++ b/xen/include/xen/rangeset.h
@@ -18,14 +18,12 @@ struct spinlock;
struct rangeset;
/*
- * Initialise/destroy per-domain rangeset information.
+ * Destroy per-domain rangeset information.
*
* It is invalid to create or destroy a rangeset belonging to a domain @d
* before rangeset_domain_initialise(d) returns or after calling
* rangeset_domain_destroy(d).
*/
-void rangeset_domain_initialise(
-struct domain *d);
void rangeset_domain_destroy(
struct domain *d);
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [RFC 1/6] rangeset_new() refactoring
From: Andrii Anisov
rangeset_new is made domain agnostic. The domain specific code
is moved to common/domain.c:domain_rangeset_new().
It is still left a rangesets list functionality: rangeset_new() is
returning its list head if requested. This would be reconsidered
further.
Signed-off-by: Andrii Anisov
---
xen/arch/x86/domain.c | 2 +-
xen/arch/x86/hvm/ioreq.c | 4 ++--
xen/arch/x86/mm/p2m.c | 4 ++--
xen/arch/x86/setup.c | 4 ++--
xen/common/domain.c| 22 --
xen/common/rangeset.c | 12
xen/include/xen/domain.h | 3 +++
xen/include/xen/rangeset.h | 19 +++
8 files changed, 45 insertions(+), 25 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index eae643f..93f18d7 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -630,7 +630,7 @@ int arch_domain_create(struct domain *d, unsigned int
domcr_flags,
d->arch.x86_model = boot_cpu_data.x86_model;
d->arch.ioport_caps =
-rangeset_new(d, "I/O Ports", RANGESETF_prettyprint_hex);
+domain_rangeset_new(d, "I/O Ports", RANGESETF_prettyprint_hex);
rc = -ENOMEM;
if ( d->arch.ioport_caps == NULL )
goto fail;
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 88071ab..6df191d 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -520,8 +520,8 @@ static int hvm_ioreq_server_alloc_rangesets(struct
hvm_ioreq_server *s,
if ( rc )
goto fail;
-s->range[i] = rangeset_new(s->domain, name,
- RANGESETF_prettyprint_hex);
+s->range[i] = domain_rangeset_new(s->domain, name,
+ RANGESETF_prettyprint_hex);
xfree(name);
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 6a45185..46301ad 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -122,8 +122,8 @@ static int p2m_init_hostp2m(struct domain *d)
if ( p2m )
{
-p2m->logdirty_ranges = rangeset_new(d, "log-dirty",
-RANGESETF_prettyprint_hex);
+p2m->logdirty_ranges = domain_rangeset_new(d, "log-dirty",
+ RANGESETF_prettyprint_hex);
if ( p2m->logdirty_ranges )
{
d->arch.p2m = p2m;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index b130671..69a961c 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1419,8 +1419,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
/* Low mappings were only needed for some BIOS table parsing. */
zap_low_mappings();
-mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
- RANGESETF_prettyprint_hex);
+mmio_ro_ranges = rangeset_new("r/o mmio ranges",
+ RANGESETF_prettyprint_hex, NULL);
init_apic_mappings();
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 3abaca9..1b9bc3c 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -329,8 +329,8 @@ struct domain *domain_create(domid_t domid, unsigned int
domcr_flags,
rangeset_domain_initialise(d);
init_status |= INIT_rangeset;
-d->iomem_caps = rangeset_new(d, "I/O Memory", RANGESETF_prettyprint_hex);
-d->irq_caps = rangeset_new(d, "Interrupts", 0);
+d->iomem_caps = domain_rangeset_new(d, "I/O Memory",
RANGESETF_prettyprint_hex);
+d->irq_caps = domain_rangeset_new(d, "Interrupts", 0);
if ( (d->iomem_caps == NULL) || (d->irq_caps == NULL) )
goto fail;
@@ -1537,6 +1537,24 @@ int continue_hypercall_on_cpu(
return 0;
}
+struct rangeset *domain_rangeset_new(struct domain *d, char *name,
+ unsigned int flags)
+{
+struct list_head *head;
+struct rangeset *r = rangeset_new(name, flags, &head);
+
+if ( d != NULL )
+{
+spin_lock(&d->rangesets_lock);
+list_add(head, &d->rangesets);
+spin_unlock(&d->rangesets_lock);
+}
+
+return r;
+}
+
+
+
/*
* Local variables:
* mode: C
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index 6c6293c..478d232 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -322,8 +322,8 @@ bool_t rangeset_is_empty(
return ((r == NULL) || list_empty(&r->range_list));
}
-struct rangeset *rangeset_new(
-struct domain *d, char *name, unsigned int flags)
+struct rangeset *rangeset_new(char *name, unsigned int flags,
+ struct list_head **head)
{
struct rangeset *r;
@@ -347,12 +347,8 @@ struct rangeset *rangeset_new(
snprintf(r->name, sizeof(r->name), "(no name)");
}
-if ( (r->domain = d) != NULL )
-{
-spin_lock(&d->rangesets_lock);
-list_add(&r->rangeset_list, &d->rangesets);
-spin_unlock(&d->rangesets_lock);
-
[Xen-devel] [RFC 2/6] rangeset_destroy() refactoring
From: Andrii Anisov
rangeset_destroy is made domain agnostic. The domain specific code
is moved to common/domain.c:domain_rangeset_destroy().
It is still left a rangesets list functionality: rangeset_destroy()
will remove itself from a list. If a spinlock is provided it will be
held for list deletion operation. This would be reconsidered further.
Signed-off-by: Andrii Anisov
---
xen/arch/x86/hvm/ioreq.c | 2 +-
xen/arch/x86/mm/p2m.c | 2 +-
xen/common/domain.c| 5 +
xen/common/rangeset.c | 15 ---
xen/include/xen/domain.h | 3 +++
xen/include/xen/rangeset.h | 9 ++---
6 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 6df191d..6ae5921 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -496,7 +496,7 @@ static void hvm_ioreq_server_free_rangesets(struct
hvm_ioreq_server *s,
return;
for ( i = 0; i < NR_IO_RANGE_TYPES; i++ )
-rangeset_destroy(s->range[i]);
+domain_rangeset_destroy(s->range[i], s->domain);
}
static int hvm_ioreq_server_alloc_rangesets(struct hvm_ioreq_server *s,
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 46301ad..d39c093 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -141,7 +141,7 @@ static void p2m_teardown_hostp2m(struct domain *d)
if ( p2m )
{
-rangeset_destroy(p2m->logdirty_ranges);
+domain_rangeset_destroy(p2m->logdirty_ranges, d);
p2m_free_one(p2m);
d->arch.p2m = NULL;
}
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 1b9bc3c..f03a032 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1553,6 +1553,11 @@ struct rangeset *domain_rangeset_new(struct domain *d,
char *name,
return r;
}
+void domain_rangeset_destroy(struct domain *d,
+struct rangeset *r)
+{
+rangeset_destroy(r, &d->rangesets_lock);
+}
/*
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index 478d232..1172950 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -354,19 +354,20 @@ struct rangeset *rangeset_new(char *name, unsigned int
flags,
}
void rangeset_destroy(
-struct rangeset *r)
+struct rangeset *r, spinlock_t *lock)
{
struct range *x;
if ( r == NULL )
return;
-if ( r->domain != NULL )
-{
-spin_lock(&r->domain->rangesets_lock);
-list_del(&r->rangeset_list);
-spin_unlock(&r->domain->rangesets_lock);
-}
+if ( lock )
+spin_lock(lock);
+
+list_del(&r->rangeset_list);
+
+if ( lock )
+spin_unlock(lock);
while ( (x = first_range(r)) != NULL )
destroy_range(r, x);
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index cd62e6e..3d9c652 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -111,4 +111,7 @@ void vnuma_destroy(struct vnuma_info *vnuma);
struct rangeset *domain_rangeset_new(struct domain *d, char *name,
unsigned int flags);
+void domain_rangeset_destroy(struct domain *d,
+struct rangeset *r);
+
#endif /* __XEN_DOMAIN_H__ */
diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
index 395ba62..deed54d 100644
--- a/xen/include/xen/rangeset.h
+++ b/xen/include/xen/rangeset.h
@@ -14,6 +14,7 @@
struct domain;
struct list_head;
+struct spinlock;
struct rangeset;
/*
@@ -37,11 +38,13 @@ struct rangeset *rangeset_new(char *name, unsigned int
flags,
struct list_head **head);
/*
- * Destroy a rangeset. It is invalid to perform any operation on a rangeset @r
+ * Destroy a rangeset. Rangeset will take an action to remove itself from a
+ * list. If a spinlock is provided it will be held during list deletion
+ * operation.
+ * It is invalid to perform any operation on a rangeset @r
* after calling rangeset_destroy(r).
*/
-void rangeset_destroy(
-struct rangeset *r);
+void rangeset_destroy(struct rangeset *r, struct spinlock *lock);
/*
* Set a limit on the number of ranges that may exist in set @r.
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [RFC 6/6] Drop domain remains from rangeset
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
xen/common/rangeset.c | 3 +--
xen/include/xen/rangeset.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index c18fb21..857615b 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -19,9 +19,8 @@ struct range {
};
struct rangeset {
-/* Owning domain and threaded list of rangesets. */
+/* threaded list of rangesets. */
struct list_head rangeset_list;
-struct domain *domain;
/* Ordered list of ranges contained in this set, and protecting lock. */
struct list_head range_list;
diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
index 8fd8164..8462071 100644
--- a/xen/include/xen/rangeset.h
+++ b/xen/include/xen/rangeset.h
@@ -12,7 +12,6 @@
#include
-struct domain;
struct list_head;
struct spinlock;
struct rangeset;
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [RFC 0/6] Rangeset generalisation
From: Andrii Anisov Rangesets in XEN seems to be a pretty generic thing slightly poisoned with. domain specific funtionality in initialization and deinitialization code. So make the rangeset code generic with moving domain specific code to common/domain.c Andrii Anisov (6): rangeset_new() refactoring rangeset_destroy() refactoring Drop rangeset_domain_initialise() rangeset_domain_destroy() refactoring rangeset_domain_printk() refactoring Drop domain remains from rangeset xen/arch/x86/domain.c | 2 +- xen/arch/x86/hvm/ioreq.c | 6 ++--- xen/arch/x86/mm/p2m.c | 6 ++--- xen/arch/x86/setup.c | 4 +-- xen/common/domain.c| 48 +++ xen/common/keyhandler.c| 2 +- xen/common/rangeset.c | 63 +++--- xen/include/xen/domain.h | 9 +++ xen/include/xen/rangeset.h | 42 +++ 9 files changed, 102 insertions(+), 80 deletions(-) -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [RFC 4/6] rangeset_domain_destroy() refactoring
From: Andrii Anisov
rangeset_domain_destroy() is rather rangeset list helper and does nothing really
domain specific. So replace it with rangeset_list_destroy() helper.
Signed-off-by: Andrii Anisov
---
xen/common/domain.c| 4 ++--
xen/common/rangeset.c | 11 ---
xen/include/xen/rangeset.h | 9 ++---
3 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 7fe69c6..47c45f2 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -420,7 +420,7 @@ struct domain *domain_create(domid_t domid, unsigned int
domcr_flags,
radix_tree_destroy(&d->pirq_tree, free_pirq_struct);
}
if ( init_status & INIT_rangeset )
-rangeset_domain_destroy(d);
+rangeset_list_destroy(&d->rangesets);
if ( init_status & INIT_watchdog )
watchdog_domain_destroy(d);
if ( init_status & INIT_xsm )
@@ -815,7 +815,7 @@ static void complete_domain_destroy(struct rcu_head *head)
watchdog_domain_destroy(d);
-rangeset_domain_destroy(d);
+rangeset_list_destroy(&d->rangesets);
sched_destroy_domain(d);
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index 1a13a32..a8b5a5d 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -381,20 +381,17 @@ void rangeset_limit(
r->nr_ranges = limit;
}
-void rangeset_domain_destroy(
-struct domain *d)
+void rangeset_list_destroy(struct list_head *list)
{
struct rangeset *r;
-while ( !list_empty(&d->rangesets) )
+while ( !list_empty(list) )
{
-r = list_entry(d->rangesets.next, struct rangeset, rangeset_list);
+r = list_entry(list->next, struct rangeset, rangeset_list);
-BUG_ON(r->domain != d);
-r->domain = NULL;
list_del(&r->rangeset_list);
-rangeset_destroy(r);
+rangeset_destroy(r, NULL);
}
}
diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
index e8244a0..cc795d1 100644
--- a/xen/include/xen/rangeset.h
+++ b/xen/include/xen/rangeset.h
@@ -18,14 +18,9 @@ struct spinlock;
struct rangeset;
/*
- * Destroy per-domain rangeset information.
- *
- * It is invalid to create or destroy a rangeset belonging to a domain @d
- * before rangeset_domain_initialise(d) returns or after calling
- * rangeset_domain_destroy(d).
+ * Destroy a list of rangesets.
*/
-void rangeset_domain_destroy(
-struct domain *d);
+void rangeset_list_destroy(struct list_head *list);
/*
* Create a rangeset. Optionally attach to a specified list @head.
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [RFC 5/6] rangeset_domain_printk() refactoring
From: Andrii Anisov
rangeset_domain_printk() is split into generic rangeset_list_printk() function
and domain specific common/domain.c:domain_rangeset_printk().
Signed-off-by: Andrii Anisov
---
xen/common/domain.c| 14 ++
xen/common/keyhandler.c| 2 +-
xen/common/rangeset.c | 15 +++
xen/include/xen/domain.h | 3 +++
xen/include/xen/rangeset.h | 4 ++--
5 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 47c45f2..9b68e2f 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1560,6 +1560,20 @@ void domain_rangeset_destroy(struct domain *d,
rangeset_destroy(r, &d->rangesets_lock);
}
+void domain_rangeset_printk(
+struct domain *d)
+{
+printk("Rangesets belonging to domain %u:\n", d->domain_id);
+
+spin_lock(&d->rangesets_lock);
+
+if ( list_empty(&d->rangesets) )
+printk("None\n");
+
+rangeset_list_printk(&d->rangesets);
+
+spin_unlock(&d->rangesets_lock);
+}
/*
* Local variables:
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 16de6e8..4f237f0 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -320,7 +320,7 @@ static void dump_domains(unsigned char key)
arch_dump_domain_info(d);
-rangeset_domain_printk(d);
+domain_rangeset_printk(d);
dump_pageframe_info(d);
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index a8b5a5d..c18fb21 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -455,26 +455,17 @@ void rangeset_printk(
read_unlock(&r->lock);
}
-void rangeset_domain_printk(
-struct domain *d)
+void rangeset_list_printk(
+struct list_head *list)
{
struct rangeset *r;
-printk("Rangesets belonging to domain %u:\n", d->domain_id);
-
-spin_lock(&d->rangesets_lock);
-
-if ( list_empty(&d->rangesets) )
-printk("None\n");
-
-list_for_each_entry ( r, &d->rangesets, rangeset_list )
+list_for_each_entry ( r, list, rangeset_list )
{
printk("");
rangeset_printk(r);
printk("\n");
}
-
-spin_unlock(&d->rangesets_lock);
}
/*
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 3d9c652..b2dca15 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -114,4 +114,7 @@ struct rangeset *domain_rangeset_new(struct domain *d, char
*name,
void domain_rangeset_destroy(struct domain *d,
struct rangeset *r);
+void domain_rangeset_printk(
+struct domain *d);
+
#endif /* __XEN_DOMAIN_H__ */
diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
index cc795d1..8fd8164 100644
--- a/xen/include/xen/rangeset.h
+++ b/xen/include/xen/rangeset.h
@@ -81,8 +81,8 @@ void rangeset_swap(struct rangeset *a, struct rangeset *b);
/* Rangeset pretty printing. */
void rangeset_printk(
struct rangeset *r);
-void rangeset_domain_printk(
-struct domain *d);
+void rangeset_list_printk(
+struct list_head *list);
#endif /* __XEN_RANGESET_H__ */
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] arm/hypercall: Use the common hcall_preempted boolean
Hi Andrew, On 15/02/17 19:41, Andrew Cooper wrote: With hcall_preempted having just been made common, ARM can use use it to simplify its hypercall handling. This simplifies the continuation logic and removes the risk of accidentally skipping multiple instructions. Signed-off-by: Andrew Cooper Reviewed-by: Julien Grall Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/multicall: Use the common hcall_preempted boolean
Hi Andrew, On 15/02/17 19:41, Andrew Cooper wrote: The now-common hcall_preempted boolean is perfectly usable for multicalls. Remove the multicall-specific preemption mechanism. Signed-off-by: Andrew Cooper For the ARM bits: Reviewed-by: Julien Grall Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 1/6] rangeset_new() refactoring
> -Original Message-
> From: Andrii Anisov [mailto:andrii.ani...@gmail.com]
> Sent: 16 February 2017 12:03
> To: xen-de...@lists.xenproject.org
> Cc: andrii_ani...@epam.com; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ;
> jbeul...@suse.com; konrad.w...@oracle.com; Paul Durrant
> ; sstabell...@kernel.org; Tim (Xen.org)
> ; Wei Liu
> Subject: [RFC 1/6] rangeset_new() refactoring
>
> From: Andrii Anisov
>
> rangeset_new is made domain agnostic. The domain specific code
> is moved to common/domain.c:domain_rangeset_new().
>
> It is still left a rangesets list functionality: rangeset_new() is
> returning its list head if requested. This would be reconsidered
> further.
>
> Signed-off-by: Andrii Anisov
> ---
> xen/arch/x86/domain.c | 2 +-
> xen/arch/x86/hvm/ioreq.c | 4 ++--
> xen/arch/x86/mm/p2m.c | 4 ++--
> xen/arch/x86/setup.c | 4 ++--
> xen/common/domain.c| 22 --
> xen/common/rangeset.c | 12
> xen/include/xen/domain.h | 3 +++
> xen/include/xen/rangeset.h | 19 +++
> 8 files changed, 45 insertions(+), 25 deletions(-)
>
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index eae643f..93f18d7 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -630,7 +630,7 @@ int arch_domain_create(struct domain *d, unsigned
> int domcr_flags,
> d->arch.x86_model = boot_cpu_data.x86_model;
>
> d->arch.ioport_caps =
> -rangeset_new(d, "I/O Ports", RANGESETF_prettyprint_hex);
> +domain_rangeset_new(d, "I/O Ports", RANGESETF_prettyprint_hex);
> rc = -ENOMEM;
> if ( d->arch.ioport_caps == NULL )
> goto fail;
> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> index 88071ab..6df191d 100644
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -520,8 +520,8 @@ static int hvm_ioreq_server_alloc_rangesets(struct
> hvm_ioreq_server *s,
> if ( rc )
> goto fail;
>
> -s->range[i] = rangeset_new(s->domain, name,
> - RANGESETF_prettyprint_hex);
> +s->range[i] = domain_rangeset_new(s->domain, name,
> + RANGESETF_prettyprint_hex);
>
> xfree(name);
>
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 6a45185..46301ad 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -122,8 +122,8 @@ static int p2m_init_hostp2m(struct domain *d)
>
> if ( p2m )
> {
> -p2m->logdirty_ranges = rangeset_new(d, "log-dirty",
> -RANGESETF_prettyprint_hex);
> +p2m->logdirty_ranges = domain_rangeset_new(d, "log-dirty",
> +
> RANGESETF_prettyprint_hex);
> if ( p2m->logdirty_ranges )
> {
> d->arch.p2m = p2m;
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index b130671..69a961c 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1419,8 +1419,8 @@ void __init noreturn __start_xen(unsigned long
> mbi_p)
> /* Low mappings were only needed for some BIOS table parsing. */
> zap_low_mappings();
>
> -mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
> - RANGESETF_prettyprint_hex);
> +mmio_ro_ranges = rangeset_new("r/o mmio ranges",
> + RANGESETF_prettyprint_hex, NULL);
>
> init_apic_mappings();
>
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 3abaca9..1b9bc3c 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -329,8 +329,8 @@ struct domain *domain_create(domid_t domid,
> unsigned int domcr_flags,
> rangeset_domain_initialise(d);
> init_status |= INIT_rangeset;
>
> -d->iomem_caps = rangeset_new(d, "I/O Memory",
> RANGESETF_prettyprint_hex);
> -d->irq_caps = rangeset_new(d, "Interrupts", 0);
> +d->iomem_caps = domain_rangeset_new(d, "I/O Memory",
> RANGESETF_prettyprint_hex);
> +d->irq_caps = domain_rangeset_new(d, "Interrupts", 0);
> if ( (d->iomem_caps == NULL) || (d->irq_caps == NULL) )
> goto fail;
>
> @@ -1537,6 +1537,24 @@ int continue_hypercall_on_cpu(
> return 0;
> }
>
> +struct rangeset *domain_rangeset_new(struct domain *d, char *name,
> + unsigned int flags)
> +{
> +struct list_head *head;
> +struct rangeset *r = rangeset_new(name, flags, &head);
> +
> +if ( d != NULL )
Shouldn't d == NULL be a hard error now, in which you could pass d->rangesets
directly into rangeset_new() (under lock).
Paul
> +{
> +spin_lock(&d->rangesets_lock);
> +list_add(head, &d->rangesets);
> +spin_unlock(&d->rangesets_lock);
> +}
> +
> +return r;
> +}
> +
> +
> +
> /*
> * Local variables:
> * mode: C
> diff --git a/xen/common/
Re: [Xen-devel] Xen on ARM IRQ latency and scheduler overhead
On Fri, 2017-02-10 at 10:32 -0800, Stefano Stabellini wrote: > On Fri, 10 Feb 2017, Dario Faggioli wrote: > > Right, interesting use case. I'm glad to see there's some interest > > in > > it, and am happy to help investigating, and trying to make things > > better. > > Thank you! > Hey, FYI, I am looking into this. It's just that I've got a couple of other things in my plate right now. > > Ok, do you (or anyone) mind explaining in a little bit more details > > what the app tries to measure and how it does that. > > Give a look at app/xen/guest_irq_latency/apu.c: > > https://github.com/edgarigl/tbm/blob/master/app/xen/guest_irq_latency > /apu.c > > This is my version which uses the phys_timer (instead of the > virt_timer): > > https://github.com/sstabellini/tbm/blob/phys-timer/app/xen/guest_irq_ > latency/apu.c > Yep, I did look at those. > Edgar can jump in to add more info if needed (he is the author of the > app), but as you can see from the code, the app is very simple. It > sets > a timer event in the future, then, after receiving the event, it > checks > the current time and compare it with the deadline. > Right, and you check the current time with: now = aarch64_irq_get_stamp(el); which I guess is compatible with the values you use for the counter. > > > These are the results, in nanosec: > > > > > > AVG MIN MAX WARM MAX > > > > > > NODEBUG no WFI 1890 1800 3170 2070 > > > NODEBUG WFI 4850 4810 7030 4980 > > > NODEBUG no WFI credit2 2217 2090 3420 2650 > > > NODEBUG WFI credit2 8080 7890 10320 8300 > > > > > > DEBUG no WFI 2252 2080 3320 2650 > > > DEBUG WFI 6500 6140 8520 8130 > > > DEBUG WFI, credit2 8050 7870 10680 8450 > > > > > > DEBUG means Xen DEBUG build. > > > [...] > > > As you can see, depending on whether the guest issues a WFI or > > > not > > > while > > > waiting for interrupts, the results change significantly. > > > Interestingly, > > > credit2 does worse than credit1 in this area. > > > > > This is with current staging right? > > That's right. > So, when you have the chance, can I see the output of xl debug-key r xl dmesg Both under Credit1 and Credit2? > > I can try sending a quick patch for disabling the tick when a CPU > > is > > idle, but I'd need your help in testing it. > > That might be useful, however, if I understand this right, we don't > actually want a periodic timer in Xen just to make the system more > responsive, do we? > IMO, no. I'd call that an hack, and don't think we should go that route. Not until we have figured out and squeezed as much as possible all the other sources of latency, and that has proven not to be enough, at least. I'll send the patch. > > > Assuming that the problem is indeed the scheduler, one workaround > > > that > > > we could introduce today would be to avoid calling vcpu_unblock > > > on > > > guest > > > WFI and call vcpu_yield instead. This change makes things > > > significantly > > > better: > > > > > > AVG MIN MAX WARM > > > MAX > > > DEBUG WFI (yield, no block) 2900 2190 5130 5130 > > > DEBUG WFI (yield, no block) credit2 3514 2280 6180 5430 > > > > > > Is that a reasonable change to make? Would it cause significantly > > > more > > > power consumption in Xen (because xen/arch/arm/domain.c:idle_loop > > > might > > > not be called anymore)? > > > > > Exactly. So, I think that, as Linux has 'idle=poll', it is > > conceivable > > to have something similar in Xen, and if we do, I guess it can be > > implemented as you suggest. > > > > But, no, I don't think this is satisfying as default, not before > > trying > > to figure out what is going on, and if we can improve things in > > other > > ways. > > OK. Should I write a patch for that? I guess it would be arm specific > initially. What do you think it would be a good name for the option? > Well, I think such an option may be useful on other arches too, but we better measure/verify that before. Therefore, I'd be ok for this to be only implemented on ARM for now. As per the name, I actually like the 'idle=', and as values, what about 'sleep' or 'block' for the current default, and stick to 'poll' for the new behavior you'll implement? Or do you think it is at risk of confusion with Linux? An alternative would be something like 'wfi=[sleep,idle]', or 'wfi=[block,poll]', but that is ARM specific, and it'd mean we will need another option for making x86 behave similarly. > > But it would not be much more useful than that, IMO. > > Why? Actually I know of several potential users of Xen on ARM > interested > exactly in this use-case. They only have a statically defined number > of > guests with a total amount of vcpu lower or equal to the number of > pcpu > in the system. Wouldn't a scheduler like that help in this scenario?
Re: [Xen-devel] [RFC 2/6] rangeset_destroy() refactoring
> -Original Message-
> From: Andrii Anisov [mailto:andrii.ani...@gmail.com]
> Sent: 16 February 2017 12:03
> To: xen-de...@lists.xenproject.org
> Cc: andrii_ani...@epam.com; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ;
> jbeul...@suse.com; konrad.w...@oracle.com; Paul Durrant
> ; sstabell...@kernel.org; Tim (Xen.org)
> ; Wei Liu
> Subject: [RFC 2/6] rangeset_destroy() refactoring
>
> From: Andrii Anisov
>
> rangeset_destroy is made domain agnostic. The domain specific code
> is moved to common/domain.c:domain_rangeset_destroy().
>
> It is still left a rangesets list functionality: rangeset_destroy()
> will remove itself from a list. If a spinlock is provided it will be
> held for list deletion operation. This would be reconsidered further.
>
Maybe use the same scheme in patch #1 then and pass the lock, as well as the
list_head, into rangeset_new().
Paul
> Signed-off-by: Andrii Anisov
> ---
> xen/arch/x86/hvm/ioreq.c | 2 +-
> xen/arch/x86/mm/p2m.c | 2 +-
> xen/common/domain.c| 5 +
> xen/common/rangeset.c | 15 ---
> xen/include/xen/domain.h | 3 +++
> xen/include/xen/rangeset.h | 9 ++---
> 6 files changed, 24 insertions(+), 12 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> index 6df191d..6ae5921 100644
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -496,7 +496,7 @@ static void hvm_ioreq_server_free_rangesets(struct
> hvm_ioreq_server *s,
> return;
>
> for ( i = 0; i < NR_IO_RANGE_TYPES; i++ )
> -rangeset_destroy(s->range[i]);
> +domain_rangeset_destroy(s->range[i], s->domain);
> }
>
> static int hvm_ioreq_server_alloc_rangesets(struct hvm_ioreq_server *s,
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 46301ad..d39c093 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -141,7 +141,7 @@ static void p2m_teardown_hostp2m(struct domain
> *d)
>
> if ( p2m )
> {
> -rangeset_destroy(p2m->logdirty_ranges);
> +domain_rangeset_destroy(p2m->logdirty_ranges, d);
> p2m_free_one(p2m);
> d->arch.p2m = NULL;
> }
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 1b9bc3c..f03a032 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1553,6 +1553,11 @@ struct rangeset *domain_rangeset_new(struct
> domain *d, char *name,
> return r;
> }
>
> +void domain_rangeset_destroy(struct domain *d,
> +struct rangeset *r)
> +{
> +rangeset_destroy(r, &d->rangesets_lock);
> +}
>
>
> /*
> diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
> index 478d232..1172950 100644
> --- a/xen/common/rangeset.c
> +++ b/xen/common/rangeset.c
> @@ -354,19 +354,20 @@ struct rangeset *rangeset_new(char *name,
> unsigned int flags,
> }
>
> void rangeset_destroy(
> -struct rangeset *r)
> +struct rangeset *r, spinlock_t *lock)
> {
> struct range *x;
>
> if ( r == NULL )
> return;
>
> -if ( r->domain != NULL )
> -{
> -spin_lock(&r->domain->rangesets_lock);
> -list_del(&r->rangeset_list);
> -spin_unlock(&r->domain->rangesets_lock);
> -}
> +if ( lock )
> +spin_lock(lock);
> +
> +list_del(&r->rangeset_list);
> +
> +if ( lock )
> +spin_unlock(lock);
>
> while ( (x = first_range(r)) != NULL )
> destroy_range(r, x);
> diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
> index cd62e6e..3d9c652 100644
> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -111,4 +111,7 @@ void vnuma_destroy(struct vnuma_info *vnuma);
> struct rangeset *domain_rangeset_new(struct domain *d, char *name,
> unsigned int flags);
>
> +void domain_rangeset_destroy(struct domain *d,
> +struct rangeset *r);
> +
> #endif /* __XEN_DOMAIN_H__ */
> diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
> index 395ba62..deed54d 100644
> --- a/xen/include/xen/rangeset.h
> +++ b/xen/include/xen/rangeset.h
> @@ -14,6 +14,7 @@
>
> struct domain;
> struct list_head;
> +struct spinlock;
> struct rangeset;
>
> /*
> @@ -37,11 +38,13 @@ struct rangeset *rangeset_new(char *name,
> unsigned int flags,
>struct list_head **head);
>
> /*
> - * Destroy a rangeset. It is invalid to perform any operation on a rangeset
> @r
> + * Destroy a rangeset. Rangeset will take an action to remove itself from a
> + * list. If a spinlock is provided it will be held during list deletion
> + * operation.
> + * It is invalid to perform any operation on a rangeset @r
> * after calling rangeset_destroy(r).
> */
> -void rangeset_destroy(
> -struct rangeset *r);
> +void rangeset_destroy(struct rangeset *r, struct spinlock *lock);
>
> /*
> * Set a limit on the number of ranges that may exist in set @r.
> --
> 2.7.4
___
Xen-de
Re: [Xen-devel] [PATCH v2 1/2] VMX: fix VMCS race on context-switch paths
On 16/02/17 11:15, Jan Beulich wrote: > When __context_switch() is being bypassed during original context > switch handling, the vCPU "owning" the VMCS partially loses control of > it: It will appear non-running to remote CPUs, and hence their attempt > to pause the owning vCPU will have no effect on it (as it already > looks to be paused). At the same time the "owning" CPU will re-enable > interrupts eventually (the lastest when entering the idle loop) and > hence becomes subject to IPIs from other CPUs requesting access to the > VMCS. As a result, when __context_switch() finally gets run, the CPU > may no longer have the VMCS loaded, and hence any accesses to it would > fail. Hence we may need to re-load the VMCS in vmx_ctxt_switch_from(). > > Similarly, when __context_switch() is being bypassed also on the second > (switch-in) path, VMCS ownership may have been lost and hence needs > re-establishing. Since there's no existing hook to put this in, add a > new one. > > Reported-by: Kevin Mayer > Reported-by: Anshul Makkar > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper Although I would certainly prefer if we can get another round of testing on this series for confidence. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 0/6] Rangeset generalisation
> -Original Message- > From: Andrii Anisov [mailto:andrii.ani...@gmail.com] > Sent: 16 February 2017 12:03 > To: xen-de...@lists.xenproject.org > Cc: andrii_ani...@epam.com; Andrew Cooper > ; George Dunlap > ; Ian Jackson ; > jbeul...@suse.com; konrad.w...@oracle.com; Paul Durrant > ; sstabell...@kernel.org; Tim (Xen.org) > ; Wei Liu > Subject: [RFC 0/6] Rangeset generalisation > > From: Andrii Anisov > > Rangesets in XEN seems to be a pretty generic thing slightly poisoned with. > domain specific funtionality in initialization and deinitialization code. > > So make the rangeset code generic with moving domain specific code to > common/domain.c Any particular reason this series is RFC? The cleanup seems a good thing to do to me. Paul > > Andrii Anisov (6): > rangeset_new() refactoring > rangeset_destroy() refactoring > Drop rangeset_domain_initialise() > rangeset_domain_destroy() refactoring > rangeset_domain_printk() refactoring > Drop domain remains from rangeset > > xen/arch/x86/domain.c | 2 +- > xen/arch/x86/hvm/ioreq.c | 6 ++--- > xen/arch/x86/mm/p2m.c | 6 ++--- > xen/arch/x86/setup.c | 4 +-- > xen/common/domain.c| 48 +++ > xen/common/keyhandler.c| 2 +- > xen/common/rangeset.c | 63 +++- > -- > xen/include/xen/domain.h | 9 +++ > xen/include/xen/rangeset.h | 42 +++ > 9 files changed, 102 insertions(+), 80 deletions(-) > > -- > 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] VMX: fix VMCS race on context-switch paths
>>> On 16.02.17 at 13:27, wrote: > On 16/02/17 11:15, Jan Beulich wrote: >> When __context_switch() is being bypassed during original context >> switch handling, the vCPU "owning" the VMCS partially loses control of >> it: It will appear non-running to remote CPUs, and hence their attempt >> to pause the owning vCPU will have no effect on it (as it already >> looks to be paused). At the same time the "owning" CPU will re-enable >> interrupts eventually (the lastest when entering the idle loop) and >> hence becomes subject to IPIs from other CPUs requesting access to the >> VMCS. As a result, when __context_switch() finally gets run, the CPU >> may no longer have the VMCS loaded, and hence any accesses to it would >> fail. Hence we may need to re-load the VMCS in vmx_ctxt_switch_from(). >> >> Similarly, when __context_switch() is being bypassed also on the second >> (switch-in) path, VMCS ownership may have been lost and hence needs >> re-establishing. Since there's no existing hook to put this in, add a >> new one. >> >> Reported-by: Kevin Mayer >> Reported-by: Anshul Makkar >> Signed-off-by: Jan Beulich > > Reviewed-by: Andrew Cooper > > Although I would certainly prefer if we can get another round of testing > on this series for confidence. Sure, I'd certainly like to stick a Tested-by on it. Plus VMX maintainer feedback will need waiting for anyway. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] xen/include: Include xen/kconfig.h automatically
>>> On 16.02.17 at 12:59, wrote: > On 16/02/17 11:10, Jan Beulich wrote: > On 16.02.17 at 12:01, wrote: >>> On 16/02/17 10:48, Jan Beulich wrote: >>> On 16.02.17 at 11:40, wrote: > On 16/02/17 10:27, Jan Beulich wrote: > On 15.02.17 at 19:10, wrote: >>> generated/autoconf.h is already included automatically so CONFIG_* >>> defines >>> are >>> avaialble. However, the companion macros such as IS_ENABLED() are not >>> included. >>> >>> Include them uniformally everywhere. >> Well, if you really think this is a good idea, I'm not going to stand in >> the way, but why do we need this included everywhere? Many files >> don't even care about any CONFIG_*, and hence even less so about >> kconfig.h. > I am sorry, but you are complaining if I include it unilaterally, and > also complaining if I include kconfig.h in the specific location where I > need it. These are mutually exclusive. I don't understand - when did I complain about its inclusion where it's needed? Iirc my complaint was about you adding the inclusion to */config.h without that header actually using the macros. My point really is that ideally each C file would get as little cruft as possible, while at present quite a number of header are being included by virtually every source file. >>> Your complaint was specifically about me adding it to paging.h so I >>> could use IS_ENABLED() and not out-of-line a trivial function. >> Oh, that one: There my view was the other way around: No need >> to include yet another header in one which already gets included >> everywhere, when the new function could easily be out of line (as >> not being performance critical). >> >>> As for general availably, while I agree in general that we have far too >>> much stuff included by default (I have some plans for that), the >>> contents of kconfig.h is fairly small, and exactly the same category of >>> information as config.h >>> >>> I am looking to push for the use of IS_ENABLED() in preference to #ifdef >>> where possible, to reduce code-rot. >> Which makes sense, but won't affect said source files not using any >> CONFIG_* in the first place. > > We already include CONFIG_* everywhere. All this change does is > consistently add IS_ENABLED() alongside, so it can be used when CONFIG_* > are available. The relevant aspect isn't CONFIG_* being available, but any of them being actually used. > If we have occasion in the future to reconsider having the CONFIG_* > variables unilaterally included, then fine, but the current state of the > code is the worst of all options. I don't think so, but as said, I'm not meaning to stand in the way of this patch going in (as making the current situation only marginally worse). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 0/6] Rangeset generalisation
Dear Paul, > The cleanup seems a good thing to do to me. So I would collect comments, rebase it to latest master and push the second version without RFC. > Any particular reason this series is RFC? The reason to make this series was an intention to use rangesets to manage mmio ranges in our shared coprocessor framework. It was planned to extend range with `void* priv` to extend functionality. Unfortunately the rangeset feature to merge ranges makes it unusable for our needs. Also linked list, even sorted, is not really good in search. Another concern was how community react on the change into generic code. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 0/6] Rangeset generalisation
> -Original Message- > From: Andrii Anisov [mailto:andrii.ani...@gmail.com] > Sent: 16 February 2017 12:46 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; andrii_ani...@epam.com; Andrew > Cooper ; George Dunlap > ; Ian Jackson ; > jbeul...@suse.com; konrad.w...@oracle.com; sstabell...@kernel.org; Tim > (Xen.org) ; Wei Liu > Subject: Re: [RFC 0/6] Rangeset generalisation > > Dear Paul, > > > The cleanup seems a good thing to do to me. > > So I would collect comments, rebase it to latest master and push the > second version without RFC. > > > Any particular reason this series is RFC? > > The reason to make this series was an intention to use rangesets to > manage mmio ranges in our shared coprocessor framework. It was planned > to extend range with `void* priv` to extend functionality. > Unfortunately the rangeset feature to merge ranges makes it unusable > for our needs. Also linked list, even sorted, is not really good in > search. > Another concern was how community react on the change into generic code. Many moons ago there were patches to use rbtree for rangesets. Perhaps it would be worth reviving that idea? Paul > > Sincerely, > Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] libxl: correct xenstore entry for empty cdrom
On Wed, Feb 15, 2017 at 12:11:12PM +0100, Juergen Gross wrote: > Specifying an empty cdrom device will result in a Xenstore entry > > params = aio:(null) > > as the physical device path isn't existing. This lets a domain booted > via OVMF hang as OVMF is checking for "aio:" only in order to detect > the empty cdrom case. > > Use an empty string for the physical device path in this case. As a > cdrom device for HVM is always backed by qdisk we only need to cover this > backend. > > Signed-off-by: Juergen Gross > --- Acked + applied ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] tools/libxc: Introduce XC_CPUPOOL_POOLID_ANY
Both patches applied. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 0/6] Rangeset generalisation
Dear Paul, > Many moons ago there were patches to use rbtree for rangesets. Perhaps it > would be worth reviving that idea? rbtree is a thing I think of now for our needs. Even more, currently I think of refactoring ARM mmio ranges managing to use rbtree one day. Currently there is a static array of 16 ranges maximum with sort on insert and bsearch there. With introducing of shared coprocessor framework system would need more mmio ranges, and dynamic data structure fast search capable looks good to fit their needs. I assume Julien did not consider rangesets for ARM mmio managing due to no range priv data for r/w handlers, linked list search slowness and ranges merging capabilities. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 1/6] rangeset_new() refactoring
>> +if ( d != NULL ) > > Shouldn't d == NULL be a hard error now, in which you could pass d->rangesets > directly into rangeset_new() (under lock). It definitely should. Because this is a domain specific code. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.6-testing test] 105831: tolerable FAIL - PUSHED
flight 105831 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105831/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105685 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105685 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105685 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 105685 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105685 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 105685 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 105685 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-4 62 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-2 62 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-1 62 xtf/test-pv32pae-xsa-194 fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-xtf-amd64-amd64-3 62 xtf/test-pv32pae-xsa-194 fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-xtf-amd64-amd64-5 62 xtf/test-pv32pae-xsa-194 fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 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-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass version targeted for testing: xen 8e04cb25d9634995fe9b37d05c63cdb4ce8c205e baseline version: xen 576f319a804bce8c9a7fb70a042f873f5eaf0151 Last test of basis 105685 2017-02-10 06:38:10 Z6 days Testing same since 105816 2017-02-15 12:43:23 Z1 days2 attempts People who touched revisions under test: Jan Beulich Julien Grall Oleksandr Tyshchenko jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvops
Re: [Xen-devel] [RFC 0/6] Rangeset generalisation
Paul, > Many moons ago there were patches to use rbtree for rangesets. Perhaps it > would be worth reviving that idea? Do you have a link to look at those patches? Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 0/6] Rangeset generalisation
>>> On 16.02.17 at 13:45, wrote: > Dear Paul, > >> The cleanup seems a good thing to do to me. > > So I would collect comments, rebase it to latest master and push the > second version without RFC. > >> Any particular reason this series is RFC? > > The reason to make this series was an intention to use rangesets to > manage mmio ranges in our shared coprocessor framework. If this is meant to be per-domain management - how many such ranges do you expect to be necessary for any one domain? We've had attempts before to (ab)use rangesets for such a purpose. > It was planned > to extend range with `void* priv` to extend functionality. > Unfortunately the rangeset feature to merge ranges makes it unusable > for our needs. Also linked list, even sorted, is not really good in > search. This concern makes me assume there might be quite many of them, which then makes this a no-go for unprivileged domains. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen
On Thu, Feb 16, 2017 at 12:06:18PM +0100, Thomas Monjalon wrote: > 2016-11-11 04:49, Tan, Jianfeng: > > Hi Thomas and Konrad, > > > > On 11/11/2016 2:59 AM, Konrad Rzeszutek Wilk wrote: > > > On Wed, Nov 9, 2016 at 5:03 PM, Thomas Monjalon wrote: > > >> 2016-11-07 07:38, Jianfeng Tan: > > >>> As some users are still using xen as the hypervisor, I suggest to > > >>> continue support for xen in DPDK. And from 16.11, I will be the > > >>> maintainer of all xen-related files. > > >>> > > >>> Signed-off-by: Jianfeng Tan > > >> Applied > > >> > > >> Please Jianfeng, could you start your new role by sending a status > > >> of Xen dom0 support in DPDK? I think there are some issues in latest > > >> releases. > > > > Yes, I'm on this. And hope to send out update in the next week. > > > > > Pls also CC me and xen-de...@lists.xenproject.org if possible. > > > > Glad to do that. > > > > Thanks, > > Jianfeng > > Any news about Xen dom0 status in DPDK? > > I think there is not enough interest for Xen dom0 in the DPDK community. > Last time we talked about, it was because of a severe bug which is not > fixed yet: > http://dpdk.org/ml/archives/dev/2016-July/044207.html > http://dpdk.org/ml/archives/dev/2016-July/044376.html > > The request (6 month ago) was to give more time for feedbacks: > http://dpdk.org/ml/archives/dev/2016-July/044847.html > > Is it time now to officially remove Dom0 support? So we do have an prototype implementation of netback but it is waiting for review of xen-devel to the spec. And I believe the implementation does utilize some of the dom0 parts of code in DPDK. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 0/6] Rangeset generalisation
Dear Jan, > If this is meant to be per-domain management - how many such > ranges do you expect to be necessary for any one domain? We've > had attempts before to (ab)use rangesets for such a purpose. It is meant to be the per-domain management. To handle per-domain vcoproc register access emulation described here [1] in terms of shared coproc framework [2]. [1] https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg01935.html [2] https://lists.xenproject.org/archives/html/xen-devel/2016-10/msg01966.html Sincerely, Andrii Anisov. 2017-02-16 15:25 GMT+02:00 Jan Beulich : On 16.02.17 at 13:45, wrote: >> Dear Paul, >> >>> The cleanup seems a good thing to do to me. >> >> So I would collect comments, rebase it to latest master and push the >> second version without RFC. >> >>> Any particular reason this series is RFC? >> >> The reason to make this series was an intention to use rangesets to >> manage mmio ranges in our shared coprocessor framework. > > If this is meant to be per-domain management - how many such > ranges do you expect to be necessary for any one domain? We've > had attempts before to (ab)use rangesets for such a purpose. > >> It was planned >> to extend range with `void* priv` to extend functionality. >> Unfortunately the rangeset feature to merge ranges makes it unusable >> for our needs. Also linked list, even sorted, is not really good in >> search. > > This concern makes me assume there might be quite many of them, > which then makes this a no-go for unprivileged domains. > > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 0/6] Rangeset generalisation
Dear Jan, I'm really sorry, but I did not get your point here: > This concern makes me assume there might be quite many of them, > which then makes this a no-go for unprivileged domains. Could you please provide wider explanation. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen
Le 16/02/2017 à 12:06, Thomas Monjalon a écrit : The request (6 month ago) was to give more time for feedbacks: http://dpdk.org/ml/archives/dev/2016-July/044847.html Is it time now to officially remove Dom0 support? yes ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] build: add --with-rundir option to configure
On 02/16/2017 02:47 AM, Juergen Gross wrote: There have been reports that Fedora 25 uses /run instead of /var/run. Add a --with-rundir option ito configure to be able to specify that directory. Default is still /var/run. As discussed on the other thread, why not make default be the location of directory on build system? Or even have it determined at boot time? -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 0/6] Rangeset generalisation
> -Original Message- > From: Andrii Anisov [mailto:andrii.ani...@gmail.com] > Sent: 16 February 2017 13:24 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; andrii_ani...@epam.com; Andrew > Cooper ; George Dunlap > ; Ian Jackson ; > jbeul...@suse.com; konrad.w...@oracle.com; sstabell...@kernel.org; Tim > (Xen.org) ; Wei Liu > Subject: Re: [RFC 0/6] Rangeset generalisation > > Paul, > > > Many moons ago there were patches to use rbtree for rangesets. Perhaps > it would be worth reviving that idea? > Do you have a link to look at those patches? The relevant patch is: https://lists.xenproject.org/archives/html/xen-devel/2015-12/msg01619.html Paul > > Sincerely, > Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] build: add --with-rundir option to configure
On 16/02/17 13:52, Boris Ostrovsky wrote: > > > On 02/16/2017 02:47 AM, Juergen Gross wrote: >> There have been reports that Fedora 25 uses /run instead of /var/run. >> >> Add a --with-rundir option ito configure to be able to specify that >> directory. Default is still /var/run. > > As discussed on the other thread, why not make default be the location > of directory on build system? Because the build system is not the running system. It doesn't even have to be the same distro as the intended running system. (If you are getting adventurous, you can actually build RPMs on Windows 10, and install them into a CentOS system...) > > Or even have it determined at boot time? Where does this list stop? Should we manually search for the appropriate /lib, /lib64, /usr/lib, etc to find shared objects? This is exactly the kind of issue autoconf is intended to solve. It appears that newer versions of autoconf use --runstatedir for this. https://lists.gnu.org/archive/html/bug-autoconf/2013-09/msg2.html It might be worth following that for forwards compatibility. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] build: add --with-rundir option to configure
On 16/02/17 14:52, Boris Ostrovsky wrote: > > > On 02/16/2017 02:47 AM, Juergen Gross wrote: >> There have been reports that Fedora 25 uses /run instead of /var/run. >> >> Add a --with-rundir option ito configure to be able to specify that >> directory. Default is still /var/run. > > As discussed on the other thread, why not make default be the location > of directory on build system? The default when calling ./configure or when building xen? What is the default for a tree on a nfs share used by both types of systems? I don't think this solution is a sane one. > Or even have it determined at boot time? How would you do that? Test the existence of the directories? What do you do if both are existing? What do you do if one is created later in the boot process and the test is being repeated? You'd need to store the information which directory to use somewhere. This will make all components using the information more fragile as they need to read the file instead of just using the configured setting. And at last: why should we suddenly start to introduce such a behavior while all other directories are configured statically? Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 2/6] rangeset_destroy() refactoring
Dear Paul,
>> It is still left a rangesets list functionality: rangeset_destroy()
>> will remove itself from a list. If a spinlock is provided it will be
>> held for list deletion operation. This would be reconsidered further.
>>
>
> Maybe use the same scheme in patch #1 then and pass the lock, as well as the
> list_head, into rangeset_new().
Initialized list head in patch#1 is provided by rangeset to user if
user needs it to link to some list. So user should do the locking on
tree insert if it needs. Here rangeset user can not acquire the tree
head even if it has a rangeset itself, because `struct rangeset` is
not exposed via header file. So rangeset_destroy() should take care of
tree head remove and spinlock locking if needed.
I still have concerns why rangeset list keeping should be inside
rangeset itself.
Sincerely,
Andrii Anisov.
2017-02-16 14:26 GMT+02:00 Paul Durrant :
>> -Original Message-
>> From: Andrii Anisov [mailto:andrii.ani...@gmail.com]
>> Sent: 16 February 2017 12:03
>> To: xen-de...@lists.xenproject.org
>> Cc: andrii_ani...@epam.com; Andrew Cooper
>> ; George Dunlap
>> ; Ian Jackson ;
>> jbeul...@suse.com; konrad.w...@oracle.com; Paul Durrant
>> ; sstabell...@kernel.org; Tim (Xen.org)
>> ; Wei Liu
>> Subject: [RFC 2/6] rangeset_destroy() refactoring
>>
>> From: Andrii Anisov
>>
>> rangeset_destroy is made domain agnostic. The domain specific code
>> is moved to common/domain.c:domain_rangeset_destroy().
>>
>> It is still left a rangesets list functionality: rangeset_destroy()
>> will remove itself from a list. If a spinlock is provided it will be
>> held for list deletion operation. This would be reconsidered further.
>>
>
> Maybe use the same scheme in patch #1 then and pass the lock, as well as the
> list_head, into rangeset_new().
>
> Paul
>
>> Signed-off-by: Andrii Anisov
>> ---
>> xen/arch/x86/hvm/ioreq.c | 2 +-
>> xen/arch/x86/mm/p2m.c | 2 +-
>> xen/common/domain.c| 5 +
>> xen/common/rangeset.c | 15 ---
>> xen/include/xen/domain.h | 3 +++
>> xen/include/xen/rangeset.h | 9 ++---
>> 6 files changed, 24 insertions(+), 12 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
>> index 6df191d..6ae5921 100644
>> --- a/xen/arch/x86/hvm/ioreq.c
>> +++ b/xen/arch/x86/hvm/ioreq.c
>> @@ -496,7 +496,7 @@ static void hvm_ioreq_server_free_rangesets(struct
>> hvm_ioreq_server *s,
>> return;
>>
>> for ( i = 0; i < NR_IO_RANGE_TYPES; i++ )
>> -rangeset_destroy(s->range[i]);
>> +domain_rangeset_destroy(s->range[i], s->domain);
>> }
>>
>> static int hvm_ioreq_server_alloc_rangesets(struct hvm_ioreq_server *s,
>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>> index 46301ad..d39c093 100644
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -141,7 +141,7 @@ static void p2m_teardown_hostp2m(struct domain
>> *d)
>>
>> if ( p2m )
>> {
>> -rangeset_destroy(p2m->logdirty_ranges);
>> +domain_rangeset_destroy(p2m->logdirty_ranges, d);
>> p2m_free_one(p2m);
>> d->arch.p2m = NULL;
>> }
>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>> index 1b9bc3c..f03a032 100644
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -1553,6 +1553,11 @@ struct rangeset *domain_rangeset_new(struct
>> domain *d, char *name,
>> return r;
>> }
>>
>> +void domain_rangeset_destroy(struct domain *d,
>> +struct rangeset *r)
>> +{
>> +rangeset_destroy(r, &d->rangesets_lock);
>> +}
>>
>>
>> /*
>> diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
>> index 478d232..1172950 100644
>> --- a/xen/common/rangeset.c
>> +++ b/xen/common/rangeset.c
>> @@ -354,19 +354,20 @@ struct rangeset *rangeset_new(char *name,
>> unsigned int flags,
>> }
>>
>> void rangeset_destroy(
>> -struct rangeset *r)
>> +struct rangeset *r, spinlock_t *lock)
>> {
>> struct range *x;
>>
>> if ( r == NULL )
>> return;
>>
>> -if ( r->domain != NULL )
>> -{
>> -spin_lock(&r->domain->rangesets_lock);
>> -list_del(&r->rangeset_list);
>> -spin_unlock(&r->domain->rangesets_lock);
>> -}
>> +if ( lock )
>> +spin_lock(lock);
>> +
>> +list_del(&r->rangeset_list);
>> +
>> +if ( lock )
>> +spin_unlock(lock);
>>
>> while ( (x = first_range(r)) != NULL )
>> destroy_range(r, x);
>> diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
>> index cd62e6e..3d9c652 100644
>> --- a/xen/include/xen/domain.h
>> +++ b/xen/include/xen/domain.h
>> @@ -111,4 +111,7 @@ void vnuma_destroy(struct vnuma_info *vnuma);
>> struct rangeset *domain_rangeset_new(struct domain *d, char *name,
>> unsigned int flags);
>>
>> +void domain_rangeset_destroy(struct domain *d,
>> +struct rangeset *r);
>> +
>> #endif /* __XEN_DOMAIN_H__ */
>> diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/ran
[Xen-devel] [distros-debian-wheezy test] 68566: tolerable trouble: broken/pass
flight 68566 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68566/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: build-arm64 2 hosts-allocate broken never pass build-arm64-pvops 2 hosts-allocate broken never pass build-arm64 3 capture-logs broken never pass build-arm64-pvops 3 capture-logs broken never pass baseline version: flight 68541 jobs: build-amd64 pass build-arm64 broken build-armhf pass build-i386 pass build-amd64-pvopspass build-arm64-pvopsbroken build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass test-amd64-i386-i386-wheezy-netboot-pvgrub pass test-amd64-i386-amd64-wheezy-netboot-pygrub pass test-amd64-amd64-i386-wheezy-netboot-pygrub pass 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 https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 0/6] Rangeset generalisation
> The relevant patch is: > > https://lists.xenproject.org/archives/html/xen-devel/2015-12/msg01619.html Thank you for the link. I would try to realize why it is left unmerged. Sincerely, Andrii Anisov. 2017-02-16 16:02 GMT+02:00 Paul Durrant : >> -Original Message- >> From: Andrii Anisov [mailto:andrii.ani...@gmail.com] >> Sent: 16 February 2017 13:24 >> To: Paul Durrant >> Cc: xen-de...@lists.xenproject.org; andrii_ani...@epam.com; Andrew >> Cooper ; George Dunlap >> ; Ian Jackson ; >> jbeul...@suse.com; konrad.w...@oracle.com; sstabell...@kernel.org; Tim >> (Xen.org) ; Wei Liu >> Subject: Re: [RFC 0/6] Rangeset generalisation >> >> Paul, >> >> > Many moons ago there were patches to use rbtree for rangesets. Perhaps >> it would be worth reviving that idea? >> Do you have a link to look at those patches? > > The relevant patch is: > > https://lists.xenproject.org/archives/html/xen-devel/2015-12/msg01619.html > > Paul > >> >> Sincerely, >> Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 2/6] rangeset_destroy() refactoring
> -Original Message-
> From: Andrii Anisov [mailto:andrii.ani...@gmail.com]
> Sent: 16 February 2017 14:26
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; andrii_ani...@epam.com; Andrew
> Cooper ; George Dunlap
> ; Ian Jackson ;
> jbeul...@suse.com; konrad.w...@oracle.com; sstabell...@kernel.org; Tim
> (Xen.org) ; Wei Liu
> Subject: Re: [RFC 2/6] rangeset_destroy() refactoring
>
> Dear Paul,
>
> >> It is still left a rangesets list functionality: rangeset_destroy()
> >> will remove itself from a list. If a spinlock is provided it will be
> >> held for list deletion operation. This would be reconsidered further.
> >>
> >
> > Maybe use the same scheme in patch #1 then and pass the lock, as well as
> the list_head, into rangeset_new().
> Initialized list head in patch#1 is provided by rangeset to user if
> user needs it to link to some list. So user should do the locking on
> tree insert if it needs. Here rangeset user can not acquire the tree
> head even if it has a rangeset itself, because `struct rangeset` is
> not exposed via header file. So rangeset_destroy() should take care of
> tree head remove and spinlock locking if needed.
>
> I still have concerns why rangeset list keeping should be inside
> rangeset itself.
What use are rangesets if the implementation doesn't control the list/tree? How
on earth would you implement an allocation function otherwise?
Paul
>
> Sincerely,
> Andrii Anisov.
>
>
> 2017-02-16 14:26 GMT+02:00 Paul Durrant :
> >> -Original Message-
> >> From: Andrii Anisov [mailto:andrii.ani...@gmail.com]
> >> Sent: 16 February 2017 12:03
> >> To: xen-de...@lists.xenproject.org
> >> Cc: andrii_ani...@epam.com; Andrew Cooper
> >> ; George Dunlap
> >> ; Ian Jackson ;
> >> jbeul...@suse.com; konrad.w...@oracle.com; Paul Durrant
> >> ; sstabell...@kernel.org; Tim (Xen.org)
> >> ; Wei Liu
> >> Subject: [RFC 2/6] rangeset_destroy() refactoring
> >>
> >> From: Andrii Anisov
> >>
> >> rangeset_destroy is made domain agnostic. The domain specific code
> >> is moved to common/domain.c:domain_rangeset_destroy().
> >>
> >> It is still left a rangesets list functionality: rangeset_destroy()
> >> will remove itself from a list. If a spinlock is provided it will be
> >> held for list deletion operation. This would be reconsidered further.
> >>
> >
> > Maybe use the same scheme in patch #1 then and pass the lock, as well as
> the list_head, into rangeset_new().
> >
> > Paul
> >
> >> Signed-off-by: Andrii Anisov
> >> ---
> >> xen/arch/x86/hvm/ioreq.c | 2 +-
> >> xen/arch/x86/mm/p2m.c | 2 +-
> >> xen/common/domain.c| 5 +
> >> xen/common/rangeset.c | 15 ---
> >> xen/include/xen/domain.h | 3 +++
> >> xen/include/xen/rangeset.h | 9 ++---
> >> 6 files changed, 24 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> >> index 6df191d..6ae5921 100644
> >> --- a/xen/arch/x86/hvm/ioreq.c
> >> +++ b/xen/arch/x86/hvm/ioreq.c
> >> @@ -496,7 +496,7 @@ static void
> hvm_ioreq_server_free_rangesets(struct
> >> hvm_ioreq_server *s,
> >> return;
> >>
> >> for ( i = 0; i < NR_IO_RANGE_TYPES; i++ )
> >> -rangeset_destroy(s->range[i]);
> >> +domain_rangeset_destroy(s->range[i], s->domain);
> >> }
> >>
> >> static int hvm_ioreq_server_alloc_rangesets(struct hvm_ioreq_server
> *s,
> >> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> >> index 46301ad..d39c093 100644
> >> --- a/xen/arch/x86/mm/p2m.c
> >> +++ b/xen/arch/x86/mm/p2m.c
> >> @@ -141,7 +141,7 @@ static void p2m_teardown_hostp2m(struct domain
> >> *d)
> >>
> >> if ( p2m )
> >> {
> >> -rangeset_destroy(p2m->logdirty_ranges);
> >> +domain_rangeset_destroy(p2m->logdirty_ranges, d);
> >> p2m_free_one(p2m);
> >> d->arch.p2m = NULL;
> >> }
> >> diff --git a/xen/common/domain.c b/xen/common/domain.c
> >> index 1b9bc3c..f03a032 100644
> >> --- a/xen/common/domain.c
> >> +++ b/xen/common/domain.c
> >> @@ -1553,6 +1553,11 @@ struct rangeset *domain_rangeset_new(struct
> >> domain *d, char *name,
> >> return r;
> >> }
> >>
> >> +void domain_rangeset_destroy(struct domain *d,
> >> +struct rangeset *r)
> >> +{
> >> +rangeset_destroy(r, &d->rangesets_lock);
> >> +}
> >>
> >>
> >> /*
> >> diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
> >> index 478d232..1172950 100644
> >> --- a/xen/common/rangeset.c
> >> +++ b/xen/common/rangeset.c
> >> @@ -354,19 +354,20 @@ struct rangeset *rangeset_new(char *name,
> >> unsigned int flags,
> >> }
> >>
> >> void rangeset_destroy(
> >> -struct rangeset *r)
> >> +struct rangeset *r, spinlock_t *lock)
> >> {
> >> struct range *x;
> >>
> >> if ( r == NULL )
> >> return;
> >>
> >> -if ( r->domain != NULL )
> >> -{
> >> -spin_lock(&r->domain->rangesets_lock);
> >> -list_del(&r->rangeset_list);
> >> -spin_unlock(&r->domain->rang
Re: [Xen-devel] [RFC 0/6] Rangeset generalisation
>>> On 16.02.17 at 14:42, wrote: > I'm really sorry, but I did not get your point here: > >> This concern makes me assume there might be quite many of them, >> which then makes this a no-go for unprivileged domains. > > Could you please provide wider explanation. Well, as it had been discussed before, I thought you would have found it the latest along with Paul having pointed you at the patches. The issue is with resource consumption: We can't allow a guest to consume basically arbitrary amounts of memory in the rangeset control structures. Iirc this was in the context of the now stuck persistent memory support series as well as around Intel's graphics virtualization one. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] xen/arm: Add pl011 uart support in Xen for guest domains
Hi, On 15/02/17 15:38, Konrad Rzeszutek Wilk wrote: On Wed, Feb 15, 2017 at 12:53:34PM +0530, Bhupinder Thakur wrote: Hi Konrad, Thanks for the feedback. On 7 February 2017 at 00:05, Konrad Rzeszutek Wilk wrote: On Mon, Feb 06, 2017 at 11:39:08PM +0530, Bhupinder Thakur wrote: As per "VM System Specification for ARM Processors", there is a requirement for Xen to support guest console over pl011 UART, which is SBSA compliant. The changes in this patch implement the pl011 emulation in Xen and a new pl011 console support in xenconsoled. Heya! Got a couple of pointers for this RFC patch. This patch should be broken up. That is the first patch should be the one that brings in the HVM_PARAM changes along with documentation on how this would work on non-ARM systems. Since this feature is ARM specific, there are two options: 1. Define the HVM params only for ARM and keep the code which is using these HVM params in the toolstack/xenconsoled under __arm__ flag 2. Define the HVM params independent of the architecture but essentially return 0/NULL on get of these HVM params for x86 architecture. The code which is using these HVM params can then check for the returned value and take the action accordingly. In this case, the code is architecture agnostic. Which is the preferred option? 2. We already have some HVM param that are x86 specific (see HVM_PARAM_VIRIDIAN) or interpreted differently whether Xen is compiled for ARM or x86 (see HVM_PARAM_CALLBACK_IRQ). So I would keep the new HVM params ARM specific and enclosed in #ifdef. The second patch would implement this in the generic code (in xen/common/event_channel.c) - perhaps via an secondary function that is NOP on x86 but not so on ARM? Then another patch that fleshes out the emulation code in the hypervisor, then the one in console code, and lastly in libxl to turn this on/off. Is it preferable to keep the pl011 emulation feature under its own feature CONFIG flag so that it can be compiled off across Xen/toolstack/console? The CONFIG flag are only for hypervisor. I would add it as a CONFIG What do you mean by the second CONFIG? Is it the one in config/*.mk? From a short glance I would recommend you also: - Include a doc which explains how pl011 UART works, or at least a link. - Remove the #if 0 - Rip out the debug printk code. - Fix the tab/spaces alignment to match the code - Don't hardcode paths. They should be gathered from envionment variables (like the rest of xenconsoled does) - If you remove the VM_PARAM_MEMORY_EVENT_ you also need to rev up the version field. I will incorporate these review comments. - Include a knob in libxl to define whether the guest has this emulation enabled or not. And if it is disabled then the code in hypervisor should not emulate it. Since the guest is unaware whether it is using an emulated pl011, is How is it unaware? How did this work before? In normal condition, a guest should not assume a specific set of devices available. It should discover them using the firmware table (ACPI or DT). Furthermore, I agree with Konrad about adding a knob in libxl to turn on/off the PL011 available. We want to let the user choosing and it will likely be disabled by default at the beginning. it required to have a knob to enable/disable this feature? I am planning to add a new console type "pl011" in addition to "pv" and "serial" and user can connect to any of those consoles. So a guest, which has let us say both HVC and pl011 consoles enabled, user can connect to any of the consoles. What happens if a guest tries to use 'pl011' on a hypervisor that does not have this? It will receive a data abort if it is accessing a memory region not emulated or with underlying physical memory. - Return code for MMIO shouldn't be 1, but rather the proper #defines. - The vpl011_cons_intf_s looks very weird. It looks like it is missing an design document as well? That is should there be a header in include/xen/public/ file? The design was discussed in the thread "Xen ARM - Exposing a PL011 to the guest" <86800697-5057-3f14-c19f-151e81315...@arm.com>. I do agree a summary of the discussion would have been useful here. Bhupinder, can you add one in the next version? Should vpl011.h be in include/xen/public/ ? If so you need a different license for that file. I will try to move this header file in the same folder where vpl011.c is. Is the ring protocol suppose to be implemented by the Linux kernel? If so it MUST be in the public/io directory. And why does it have to be aring protocol? Why not whatever the pl011 implements? Why not emulate how pl011 works? The ring protocol is between Xen (where the pl011 is emulated) and the console backend. The guest will use a normal pl011 driver and no Xen header should be required there. For the protocol between Xen and the console backend, the ring was a natural choice because this is
Re: [Xen-devel] [PATCH] build: add --with-rundir option to configure
On 16/02/17 15:12, Andrew Cooper wrote: > On 16/02/17 13:52, Boris Ostrovsky wrote: >> >> >> On 02/16/2017 02:47 AM, Juergen Gross wrote: >>> There have been reports that Fedora 25 uses /run instead of /var/run. >>> >>> Add a --with-rundir option ito configure to be able to specify that >>> directory. Default is still /var/run. >> >> As discussed on the other thread, why not make default be the location >> of directory on build system? > > Because the build system is not the running system. It doesn't even > have to be the same distro as the intended running system. (If you are > getting adventurous, you can actually build RPMs on Windows 10, and > install them into a CentOS system...) > >> >> Or even have it determined at boot time? > > Where does this list stop? Should we manually search for the > appropriate /lib, /lib64, /usr/lib, etc to find shared objects? > > This is exactly the kind of issue autoconf is intended to solve. > > It appears that newer versions of autoconf use --runstatedir for this. > https://lists.gnu.org/archive/html/bug-autoconf/2013-09/msg2.html Yeah. From autoconf 2.70 on. Which isn't released yet. > It might be worth following that for forwards compatibility. I'm no autoconf expert. I could deduce how to use --with-*, but I'm lost with support of --runstatedir (repeating the patch you referenced would probably break using autoconf 2.70 in future...). Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] [RFC] x86/kconfig: Introduce CONFIG_PV and CONFIG_HVM
>>> On 15.02.17 at 20:41, wrote: > Making PV and HVM guests individually compilable is useful as a reduction in > hypervisor size, and as an aid to enforcing clean API boundaries. > > Introduce CONFIG_PV and CONFIG_HVM, although there is a lot of work to do > until either can actually be disabled. While this is a nice goal, is it really useful to add these config options now, rather than when that lot of work is at least near completion? Or otherwise, how about making them prompt-less for now even for EXPERT? > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -32,6 +32,56 @@ menu "Architecture Features" > > source "arch/Kconfig" > > +config PV > + def_bool y > + prompt "PV guest support" if EXPERT = "y" > + depends on X86 > + ---help--- > + Support for Xen Paravirtual guests. > + > + Xen PV guests use Ring Deprivileging as a method of virtualisation. > + This requires no specific hardware support, but does require an OS > + capable of running PV under Xen. > + > + If unsure, say Y. > + > + TODO: This is a work in process, and Xen doesn't currently compile > + if this option is disabled. > + > +config HVM > + def_bool y > + prompt "HVM guest support" if EXPERT = "y" > + depends on X86 Both of them getting selected to "no" makes extremely little sense, I think, so I would wish to have a guard against that. Maybe the user visible part wants to be a choice (both, PV only, HVM only), selecting prompt-less PV and HVM as necessary? Furthermore, considering what file they're in, I don't think the "depends on X86" are necessary here (oddly enough TBOOT has this too, but SHADOW_PAGING and BIGMEM don't). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [linux-linus test] 104684: regressions - FAIL
Hi, On 14/02/17 17:42, Wei Liu wrote: (test-lab)liuw@osstest:~/testing.git$ ./mg-hosts showprops | grep DTUART | grep arndale arndale-bluewater XenDTUARTPath /serial@12C2 arndale-lakeside XenDTUARTPath /serial@12C2 arndale-metrocentre XenDTUARTPath /serial@12C2 arndale-westfield XenDTUARTPath /serial@12C2 That's a property of this kind of hosts in osstest. It needs to be updated by the administrator (Ian). Ian, could you change the XenDTUARTPath property for the arndale from "/serial@12C2" to "serial0"? This should hopefully fix boot of Linux upstream on the board and keep compatibility with the previous version of Linux. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] [RFC] x86/kconfig: Introduce CONFIG_PV and CONFIG_HVM
On 16/02/17 14:39, Jan Beulich wrote: On 15.02.17 at 20:41, wrote: >> Making PV and HVM guests individually compilable is useful as a reduction in >> hypervisor size, and as an aid to enforcing clean API boundaries. >> >> Introduce CONFIG_PV and CONFIG_HVM, although there is a lot of work to do >> until either can actually be disabled. > While this is a nice goal, is it really useful to add these config options > now, rather than when that lot of work is at least near completion? Hence the RFC on this patch. > Or otherwise, how about making them prompt-less for now even for > EXPERT? Doesn't that prohibit them from being altered, even for development purposes? > >> --- a/xen/arch/x86/Kconfig >> +++ b/xen/arch/x86/Kconfig >> @@ -32,6 +32,56 @@ menu "Architecture Features" >> >> source "arch/Kconfig" >> >> +config PV >> +def_bool y >> +prompt "PV guest support" if EXPERT = "y" >> +depends on X86 >> +---help--- >> + Support for Xen Paravirtual guests. >> + >> + Xen PV guests use Ring Deprivileging as a method of virtualisation. >> + This requires no specific hardware support, but does require an OS >> + capable of running PV under Xen. >> + >> + If unsure, say Y. >> + >> + TODO: This is a work in process, and Xen doesn't currently compile >> + if this option is disabled. >> + >> +config HVM >> +def_bool y >> +prompt "HVM guest support" if EXPERT = "y" >> +depends on X86 > Both of them getting selected to "no" makes extremely little sense, > I think, so I would wish to have a guard against that. Maybe the > user visible part wants to be a choice (both, PV only, HVM only), > selecting prompt-less PV and HVM as necessary? There are a few edgecases whether neither would be useful, e.g. seeing if we have subsystems in the resulting compile which should be covered under PV or HVM. I also had occason to need no guests whatsoever when doing the HPET work (and I still have the debugging patch to allow Xen to run without a dom0). As this is already under EXPERT (and I expect that not to change), I don't it is too much of a problem allowing both to be disabled. > Furthermore, considering what file they're in, I don't think the > "depends on X86" are necessary here (oddly enough TBOOT has > this too, but SHADOW_PAGING and BIGMEM don't). I did find this weird. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 105837: all pass - PUSHED
flight 105837 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105837/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fd12acdeff7a04ad34ccb95103eb6204b8901749
baseline version:
ovmf cb8674999c6bf94cdb3be18df3746131aac6386b
Last test of basis 105814 2017-02-15 10:13:10 Z1 days
Testing same since 105837 2017-02-16 03:14:57 Z0 days1 attempts
People who touched revisions under test:
Liming Gao
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=fd12acdeff7a04ad34ccb95103eb6204b8901749
+ . ./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
fd12acdeff7a04ad34ccb95103eb6204b8901749
+ branch=ovmf
+ revision=fd12acdeff7a04ad34ccb95103eb6204b8901749
+ . ./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
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' xfd12acdeff7a04ad34ccb95103eb6204b8901749 = x ']'
+ : 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/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.g
[Xen-devel] [PATCH] x86/vpmu: Add get/put_vpmu() and VPMU_ENABLED
vpmu_enabled() (used by hvm/pv_cpuid() to properly report 0xa leaf
for Intel processors) is based on the value of VPMU_CONTEXT_ALLOCATED
bit. This is problematic:
* For HVM guests VPMU context is allocated lazily, during the first
access to VPMU MSRs. Since the leaf is typically queried before guest
attempts to read or write the MSRs it is likely that CPUID will report
no PMU support
* For PV guests the context is allocated eagerly but only in responce to
guest's XENPMU_init hypercall. There is a chance that the guest will
try to read CPUID before making this hypercall.
This patch introduces VPMU_ENABLED flag which is set (subject to vpmu_mode
constraints) during VCPU initialization for both PV and HVM guests. Since
this flag is expected to be managed together with vpmu_count, get/put_vpmu()
are added to simplify code.
vpmu_enabled() can now use this new flag.
(As a side affect this patch also fixes a race in pvpmu_init() where we
increment vcpu_count in vpmu_initialise() after checking vpmu_mode)
Signed-off-by: Boris Ostrovsky
---
xen/arch/x86/cpu/vpmu.c| 111 ++---
xen/arch/x86/domain.c | 5 ++
xen/arch/x86/hvm/svm/svm.c | 5 --
xen/arch/x86/hvm/vmx/vmx.c | 5 --
xen/include/asm-x86/vpmu.h | 6 ++-
5 files changed, 84 insertions(+), 48 deletions(-)
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 35a9403..283af80 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -456,32 +456,21 @@ int vpmu_load(struct vcpu *v, bool_t from_guest)
return 0;
}
-void vpmu_initialise(struct vcpu *v)
+static int vpmu_arch_initialise(struct vcpu *v)
{
struct vpmu_struct *vpmu = vcpu_vpmu(v);
uint8_t vendor = current_cpu_data.x86_vendor;
int ret;
-bool_t is_priv_vpmu = is_hardware_domain(v->domain);
BUILD_BUG_ON(sizeof(struct xen_pmu_intel_ctxt) > XENPMU_CTXT_PAD_SZ);
BUILD_BUG_ON(sizeof(struct xen_pmu_amd_ctxt) > XENPMU_CTXT_PAD_SZ);
BUILD_BUG_ON(sizeof(struct xen_pmu_regs) > XENPMU_REGS_PAD_SZ);
BUILD_BUG_ON(sizeof(struct compat_pmu_regs) > XENPMU_REGS_PAD_SZ);
-ASSERT(!vpmu->flags && !vpmu->context);
+ASSERT(!(vpmu->flags & ~VPMU_ENABLED) && !vpmu->context);
-if ( !is_priv_vpmu )
-{
-/*
- * Count active VPMUs so that we won't try to change vpmu_mode while
- * they are in use.
- * vpmu_mode can be safely updated while dom0's VPMUs are active and
- * so we don't need to include it in the count.
- */
-spin_lock(&vpmu_lock);
-vpmu_count++;
-spin_unlock(&vpmu_lock);
-}
+if ( !vpmu_enabled(v) )
+return 0;
switch ( vendor )
{
@@ -501,7 +490,7 @@ void vpmu_initialise(struct vcpu *v)
opt_vpmu_enabled = 0;
vpmu_mode = XENPMU_MODE_OFF;
}
-return; /* Don't bother restoring vpmu_count, VPMU is off forever */
+return -EINVAL;
}
vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
@@ -509,15 +498,63 @@ void vpmu_initialise(struct vcpu *v)
if ( ret )
printk(XENLOG_G_WARNING "VPMU: Initialization failed for %pv\n", v);
-/* Intel needs to initialize VPMU ops even if VPMU is not in use */
-if ( !is_priv_vpmu &&
- (ret || (vpmu_mode == XENPMU_MODE_OFF) ||
- (vpmu_mode == XENPMU_MODE_ALL)) )
+return ret;
+}
+
+static void get_vpmu(struct vcpu *v)
+{
+spin_lock(&vpmu_lock);
+
+/*
+ * Count active VPMUs so that we won't try to change vpmu_mode while
+ * they are in use.
+ * vpmu_mode can be safely updated while dom0's VPMUs are active and
+ * so we don't need to include it in the count.
+ */
+if ( !is_hardware_domain(v->domain) &&
+(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
+{
+vpmu_count++;
+vpmu_set(vcpu_vpmu(v), VPMU_ENABLED);
+}
+else if ( is_hardware_domain(v->domain) &&
+ (vpmu_mode != XENPMU_MODE_OFF) )
+vpmu_set(vcpu_vpmu(v), VPMU_ENABLED);
+
+spin_unlock(&vpmu_lock);
+}
+
+static void put_vpmu(struct vcpu *v)
+{
+if ( !vpmu_is_set(vcpu_vpmu(v), VPMU_ENABLED) )
+return;
+
+spin_lock(&vpmu_lock);
+
+if ( !is_hardware_domain(v->domain) &&
+ (vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
{
-spin_lock(&vpmu_lock);
vpmu_count--;
-spin_unlock(&vpmu_lock);
+vpmu_reset(vcpu_vpmu(v), VPMU_ENABLED);
}
+else if ( is_hardware_domain(v->domain) &&
+ (vpmu_mode != XENPMU_MODE_OFF) )
+vpmu_reset(vcpu_vpmu(v), VPMU_ENABLED);
+
+spin_unlock(&vpmu_lock);
+}
+
+
+void vpmu_initialise(struct vcpu *v)
+{
+get_vpmu(v);
+
+/*
+ * Guests without LAPIC (i.e. PV) call vpmu_arch_initialise()
+ * from pvpmu_init().
+ */
+if ( has_vlapic(v->domain) && vpmu_arch_initialise(v) )
+put_vpmu(v);
}
static void vpmu_clear_last(void *arg)
@@ -526,7
Re: [Xen-devel] Unshared IOMMU issues
Hi, Jan. On Thu, Feb 16, 2017 at 11:36 AM, Jan Beulich wrote: On 15.02.17 at 18:43, wrote: >> 1. >> I need: >> Allow P2M core on ARM to update IOMMU mapping from the first "p2m_set_entry". >> I do: >> I explicitly set need_iommu flag for *every* guest domain during >> iommu_domain_init() on ARM in case if page table is not shared. >> At that moment I have no knowledge about will any device be assigned >> to this domain or not. I am just want to receive all mapping updates >> from P2M code. The P2M will update IOMMU mapping only when need_iommu >> is set and page table is not shared. >> I have doubts: >> Is it correct to just force need_iommu flag? > > No, I don't think so. This is a waste of a measurable amount of > resources when page tables aren't shared. > >> Or maybe another flag should be introduced? > > Not sure what you think of here. Where's the problem with building > IOMMU page tables at the time the first device gets assigned, just > like x86 does? OK, I have already had a look at arch_iommu_populate_page_table() for x86. I don't know at the moment how this solution can help me. There are a least two points the prevent me from doing the similar thing. 1. For create IOMMU mapping I need both mfn and gfn. (+ flags). I am able to get mfn only. How can I find corresponding gfn? 2. The d->page_list seems only contains domain RAM (not 100% sure). Where can I get other regions (mmios, etc)? > >> Or we don't need to check for need_iommu flag before updating IOMMU >> mapping in P2M code, maybe iommu_enabled would be enough? > > No, afaict that would again mean maintaining IOMMU page tables > regardless of whether they're needed. > >> 2. >> I need: >> Allow IOMMU driver to be ready to handle IOMMU mapping updates from >> the first "p2m_set_entry". > > Why (see also the question above)? I explained above. Unfortunately, I don't see how can I get all iova-to-pa mapping that took place for this domain from the start on ARM. > >> I do: >> I always allocate IOMMU page table during iommu_domain_init() for every >> domain even this domain won't have any assigned devices in future. I >> don't wait for iommu_construct. >> I have doubts: >> Is it correct? It might be just wasting memory and CPU time if domain >> doesn't have any assigned devices in future. > > Indeed. > > Jan > -- Regards, Oleksandr Tyshchenko ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.4-testing test] 105835: tolerable trouble: blocked/broken/fail/pass - PUSHED
flight 105835 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105835/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3)broken pass in 105815 test-amd64-i386-libvirt 3 host-install(3) broken pass in 105815 test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail in 105815 pass in 105835 test-armhf-armhf-libvirt-raw 5 xen-install fail in 105815 pass in 105835 test-amd64-i386-xend-qemut-winxpsp3 9 windows-install fail in 105815 pass in 105835 Regressions which are regarded as allowable (not blocking): test-xtf-amd64-amd64-2 16 xtf/test-pv32pae-selftestfail like 103812 test-xtf-amd64-amd64-4 16 xtf/test-pv32pae-selftestfail like 103812 test-xtf-amd64-amd64-3 20 xtf/test-hvm32-invlpg~shadow fail like 103812 test-xtf-amd64-amd64-3 32 xtf/test-hvm32pae-invlpg~shadow fail like 103812 test-xtf-amd64-amd64-3 43 xtf/test-hvm64-invlpg~shadow fail like 103812 test-xtf-amd64-amd64-2 53 leak-check/check fail like 103812 test-xtf-amd64-amd64-4 53 leak-check/check fail like 103812 test-xtf-amd64-amd64-1 53 leak-check/check fail like 103812 test-xtf-amd64-amd64-5 53 leak-check/check fail like 103812 test-xtf-amd64-amd64-3 53 leak-check/check fail like 103812 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 103812 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 103812 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt 12 migrate-support-check fail in 105815 never pass test-xtf-amd64-amd64-2 10 xtf-fep fail never pass test-xtf-amd64-amd64-2 18 xtf/test-hvm32-cpuid-faulting fail never pass test-xtf-amd64-amd64-4 10 xtf-fep fail never pass test-xtf-amd64-amd64-4 18 xtf/test-hvm32-cpuid-faulting fail never pass test-xtf-amd64-amd64-2 30 xtf/test-hvm32pae-cpuid-faulting fail never pass test-xtf-amd64-amd64-1 10 xtf-fep fail never pass test-xtf-amd64-amd64-2 36 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-5 10 xtf-fep fail never pass test-xtf-amd64-amd64-4 30 xtf/test-hvm32pae-cpuid-faulting fail never pass test-xtf-amd64-amd64-2 40 xtf/test-hvm64-cpuid-faulting fail never pass test-xtf-amd64-amd64-1 16 xtf/test-pv32pae-selftestfail never pass test-xtf-amd64-amd64-1 18 xtf/test-hvm32-cpuid-faulting fail never pass test-xtf-amd64-amd64-4 36 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-4 40 xtf/test-hvm64-cpuid-faulting fail never pass test-xtf-amd64-amd64-1 30 xtf/test-hvm32pae-cpuid-faulting fail never pass test-xtf-amd64-amd64-1 36 xtf/test-hvm32pse-cpuid-faulting fail never pass test-xtf-amd64-amd64-1 40 xtf/test-hvm64-cpuid-faulting fail never pass build-amd64-rumprun 7 xen-buildfail never pass build-i386-rumprun7 xen-buildfail never pass test-xtf-amd64-amd64-3 10 xtf-fep fail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-xtf-amd64-amd64-2 52 xtf/test-hvm64-xsa-195 fail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-xtf-amd64-amd64-4 52 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-1 52 xtf/test-hvm64-xsa-195 fail never pass test-xtf-amd64-amd64-5 52 xtf/test-hvm64-xsa-195 fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass test-xtf-amd64-amd64-3 52 xtf/test-hvm64-xsa-195 fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail 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-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt 11 guest-start fail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-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-credit2 12 migrate-support-check
Re: [Xen-devel] qemu-upstream triggering OOM killer
>>> On 14.02.17 at 15:56, wrote: > On Fri, Feb 10, 2017 at 02:54:23AM -0700, Jan Beulich wrote: >> Not so far. It appears to happen when grub clears the screen >> before displaying its graphical menu, so I'd rather suspect an issue >> with a graphics related change (the one you pointed out isn't). > > I tried to reproduce this, by limiting the amount of memory available to > qemu using cgroups, but about 44MB of memory is enough to boot a guest > (tried Ubuntu and Debian). Okay, not a qemuu regression after all, but a libxc one. It just so happens that qemut tries to allocate a much larger amount, which triggers mmap() failure earlier and hence doesn't manage to trigger the oom killer. Patch (almost) on its way. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.7-testing test] 105833: regressions - trouble: blocked/broken/fail/pass
flight 105833 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105833/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail REGR. vs. 105661 Tests which are failing intermittently (not blocking): test-amd64-amd64-qemuu-nested-amd 3 host-install(3) broken pass in 105819 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 9 debian-install fail REGR. vs. 105661 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105661 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105661 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105661 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 105661 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 105661 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105661 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail in 105819 never pass build-arm64 5 xen-buildfail never pass build-arm64-xsm 5 xen-buildfail never pass build-arm64-pvops 5 kernel-build fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail 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-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 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-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail 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-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: xen 758378233b0b5d79a29735d95dc72410ef2f19aa baseline version: xen d31a0a29f5d7563b7361f7096316fd9e611d8673 Last test of basis 105661 2017-02-09 09:43:17 Z7 days Testing same since 105819 2017-02-15 12:44:07 Z1 days2 attempts People who touched revisions under test: Jan Beulich Julien Grall Oleksandr Tyshchenko jobs: build-amd64-xsm
[Xen-devel] [xen-unstable-smoke test] 105852: tolerable trouble: broken/fail/pass - PUSHED
flight 105852 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105852/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen-buildfail never pass
build-arm64-pvops 5 kernel-build fail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
version targeted for testing:
xen 7127d53fe891f9ea67357587a33a7aaba4b55f45
baseline version:
xen 1e88db4701d6e2d00c04795e6aacaea942b617e6
Last test of basis 105836 2017-02-16 02:03:26 Z0 days
Testing same since 105852 2017-02-16 14:01:33 Z0 days1 attempts
People who touched revisions under test:
George Dunlap
Juergen Gross
Wei Liu
jobs:
build-amd64 pass
build-arm64 fail
build-armhf pass
build-amd64-libvirt pass
build-arm64-pvopsfail
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm broken
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt 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=xen-unstable-smoke
+ revision=7127d53fe891f9ea67357587a33a7aaba4b55f45
+ . ./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 xen-unstable-smoke
7127d53fe891f9ea67357587a33a7aaba4b55f45
+ branch=xen-unstable-smoke
+ revision=7127d53fe891f9ea67357587a33a7aaba4b55f45
+ . ./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=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x7127d53fe891f9ea67357587a33a7aaba4b55f45 = x ']'
+ : 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/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.gi
[Xen-devel] [PATCH] libxc: don't pass uninitialized data to do_dm_op()
do_dm_op() expects (void *, size_t) pairs, but with nr being uint32_t the type of the expression of xc_hvm_track_dirty_vram()'s last argument to the function is only a 32 bits one. Neither C nor the ABI require the compiler to promote the type beyond int. Signed-off-by: Jan Beulich --- a/tools/libxc/xc_misc.c +++ b/tools/libxc/xc_misc.c @@ -609,7 +609,7 @@ int xc_hvm_track_dirty_vram( data->nr = nr; return do_dm_op(xch, dom, 2, &op, sizeof(op), -dirty_bitmap, (nr + 7) / 8); +dirty_bitmap, (size_t)((nr + 7) / 8)); } int xc_hvm_modified_memory( libxc: don't pass uninitialized data to do_dm_op() do_dm_op() expects (void *, size_t) pairs, but with nr being uint32_t the type of the expression of xc_hvm_track_dirty_vram()'s last argument to the function is only a 32 bits one. Neither C nor the ABI require the compiler to promote the type beyond int. Signed-off-by: Jan Beulich --- a/tools/libxc/xc_misc.c +++ b/tools/libxc/xc_misc.c @@ -609,7 +609,7 @@ int xc_hvm_track_dirty_vram( data->nr = nr; return do_dm_op(xch, dom, 2, &op, sizeof(op), -dirty_bitmap, (nr + 7) / 8); +dirty_bitmap, (size_t)((nr + 7) / 8)); } int xc_hvm_modified_memory( ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
