[Xen-devel] [distros-debian-squeeze test] 72166: tolerable trouble: broken/fail/pass
flight 72166 distros-debian-squeeze real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72166/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: build-arm64-pvops 2 hosts-allocate broken like 72130 build-arm64 2 hosts-allocate broken like 72130 build-arm64-pvops 3 capture-logs broken like 72130 build-arm64 3 capture-logs broken like 72130 test-amd64-amd64-amd64-squeeze-netboot-pygrub 10 debian-di-install fail like 72130 test-amd64-i386-i386-squeeze-netboot-pygrub 10 debian-di-install fail like 72130 test-amd64-i386-amd64-squeeze-netboot-pygrub 10 debian-di-install fail like 72130 test-amd64-amd64-i386-squeeze-netboot-pygrub 10 debian-di-install fail like 72130 baseline version: flight 72130 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-squeeze-netboot-pygrubfail test-amd64-i386-amd64-squeeze-netboot-pygrub fail test-amd64-amd64-i386-squeeze-netboot-pygrub fail test-amd64-i386-i386-squeeze-netboot-pygrub fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5] x86/hvm: Implement hvmemul_write() using real mappings
From: Andrew Cooper
An access which crosses a page boundary is performed atomically by x86
hardware, albeit with a severe performance penalty. An important corner case
is when a straddled access hits two pages which differ in whether a
translation exists, or in net access rights.
The use of hvm_copy*() in hvmemul_write() is problematic, because it performs
a translation then completes the partial write, before moving onto the next
translation.
If an individual emulated write straddles two pages, the first of which is
writable, and the second of which is not, the first half of the write will
complete before #PF is raised from the second half.
This results in guest state corruption as a side effect of emulation, which
has been observed to cause windows to crash while under introspection.
Introduce the hvmemul_{,un}map_linear_addr() helpers, which translate an
entire contents of a linear access, and vmap() the underlying frames to
provide a contiguous virtual mapping for the emulator to use. This is the
same mechanism as used by the shadow emulation code.
This will catch any translation issues and abort the emulation before any
modifications occur.
Signed-off-by: Andrew Cooper
Signed-off-by: Alexandru Isaila
---
Changes since V4:
- Moved the mfn increment line back
- Removed the new line between mfn++ and while
Reviewed-by: Paul Durrant
---
xen/arch/x86/hvm/emulate.c| 174 ++
xen/include/asm-x86/hvm/emulate.h | 7 ++
2 files changed, 164 insertions(+), 17 deletions(-)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index cc874ce..9d8be30 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -498,6 +498,156 @@ static int hvmemul_do_mmio_addr(paddr_t mmio_gpa,
}
/*
+ * Map the frame(s) covering an individual linear access, for writeable
+ * access. May return NULL for MMIO, or ERR_PTR(~X86EMUL_*) for other errors
+ * including ERR_PTR(~X86EMUL_OKAY) for write-discard mappings.
+ *
+ * In debug builds, map() checks that each slot in hvmemul_ctxt->mfn[] is
+ * clean before use, and poisions unused slots with INVALID_MFN.
+ */
+static void *hvmemul_map_linear_addr(
+unsigned long linear, unsigned int bytes, uint32_t pfec,
+struct hvm_emulate_ctxt *hvmemul_ctxt)
+{
+struct vcpu *curr = current;
+void *err, *mapping;
+
+/* First and final gfns which need mapping. */
+unsigned long frame = linear >> PAGE_SHIFT, first = frame;
+unsigned long final = (linear + bytes - !!bytes) >> PAGE_SHIFT;
+
+/*
+ * mfn points to the next free slot. All used slots have a page reference
+ * held on them.
+ */
+mfn_t *mfn = &hvmemul_ctxt->mfn[0];
+
+/*
+ * The caller has no legitimate reason for trying a zero-byte write, but
+ * final is calculate to fail safe in release builds.
+ *
+ * The maximum write size depends on the number of adjacent mfns[] which
+ * can be vmap()'d, accouting for possible misalignment within the region.
+ * The higher level emulation callers are responsible for ensuring that
+ * mfns[] is large enough for the requested write size.
+ */
+if ( bytes == 0 ||
+ final - first >= ARRAY_SIZE(hvmemul_ctxt->mfn) )
+{
+ASSERT_UNREACHABLE();
+goto unhandleable;
+}
+
+do {
+enum hvm_translation_result res;
+struct page_info *page;
+pagefault_info_t pfinfo;
+p2m_type_t p2mt;
+
+/* Error checking. Confirm that the current slot is clean. */
+ASSERT(mfn_x(*mfn) == 0);
+
+res = hvm_translate_get_page(curr, frame << PAGE_SHIFT, true, pfec,
+ &pfinfo, &page, NULL, &p2mt);
+
+switch ( res )
+{
+case HVMTRANS_okay:
+break;
+
+case HVMTRANS_bad_linear_to_gfn:
+x86_emul_pagefault(pfinfo.ec, pfinfo.linear, &hvmemul_ctxt->ctxt);
+err = ERR_PTR(~X86EMUL_EXCEPTION);
+goto out;
+
+case HVMTRANS_bad_gfn_to_mfn:
+err = NULL;
+goto out;
+
+case HVMTRANS_gfn_paged_out:
+case HVMTRANS_gfn_shared:
+err = ERR_PTR(~X86EMUL_RETRY);
+goto out;
+
+default:
+goto unhandleable;
+}
+
+*mfn++ = _mfn(page_to_mfn(page));
+
+if ( p2m_is_discard_write(p2mt) )
+{
+err = ERR_PTR(~X86EMUL_OKAY);
+goto out;
+}
+
+} while ( ++frame < final );
+
+/* Entire access within a single frame? */
+if ( first == final )
+mapping = map_domain_page(hvmemul_ctxt->mfn[0]);
+/* Multiple frames? Need to vmap(). */
+else if ( (mapping = vmap(hvmemul_ctxt->mfn,
+ final - first + 1)) == NULL )
+goto unhandleable;
+
+#ifndef NDEBUG /* Poision unused mfn[]s with INVALID_MFN. */
+while ( mfn < hvmemul_ctxt->mfn + ARRAY_SIZE(hvmemul_ctxt->mfn) )
Re: [Xen-devel] [PATCH 1/3] xen: timers: don't miss a timer event because of stop_timer()
>>> On 26.09.17 at 20:11, wrote:
> On Tue, 2017-09-26 at 08:59 -0600, Jan Beulich wrote:
>> > > > On 15.09.17 at 20:01, wrote:
>> > @@ -326,7 +326,17 @@ void stop_timer(struct timer *timer)
>> > return;
>> >
>> > if ( active_timer(timer) )
>> > -deactivate_timer(timer);
>> > +{
>> > +/*
>> > + * If the timer is expired already, 'call' the softirq
>> > handler to
>> > + * execute it (it will leave it inactive after that). If
>> > not, just
>> > + * deactivate it.
>> > + */
>> > +if ( timer->expires <= NOW() )
>> > +cpu_raise_softirq(timer->cpu, TIMER_SOFTIRQ);
>> > +else
>> > +deactivate_timer(timer);
>> > +}
>>
>> Isn't it reasonable to expect current behavior, i.e. the timer not
>> raising any events other than those already in progress?
>>
> Well, if we managed to get to here, with the timer that is both:
> - active,
> - with its expiry time in the past,
>
> it means there is an event that *is* in progress right now (i.e., we're
> stopping the timer on the path that goes from the interrupt that raised
> TIMER_SOFTIRQ, and the timer softirq handler).
>
> So, basically, I'm trying to achieve exactly what you call reasonable:
> servicing an event which is in progress. :-)
I'm afraid I don't understand - if the processing of the timer is
already in progress, why would you need to raise another
softirq? Wouldn't it suffice to simply skip deactivate_timer() then?
This raising of the softirq is what made me imply that, perhaps
due to some minimal skew e.g. resulting from rounding, you
assume the interrupt did not fire yet, which I'd then call the
timer event not being in progress (yet).
> The alternative is that the event happened, but we somehow managed to
> miss running the timer handler for it, and we realize this only now,
> potentially a long time after the miss. This scenario, as far as I can
> tell, can't happen, but if it could/does, I'd still say running the
> handler late is better than not running it at all.
Well, as said - what's better may very well depend on the particular
use case. As long as it's not clearly written down what the intended
behavior is, both behaviors are acceptable imo.
In the end what I think I'm missing is a clear description of an actual
case where the current behavior causes breakage (plus of course
an explanation why the new behavior is unlikely to cause issues with
existing users).
>> Additionally I'm not convinced the changed actually does what you
>> want: What if NOW() becomes equal to timer->expires immediately
>> after you've managed to obtain its value, before execution makes
>> it into deactivate_timer()? IOW you're shrinking a time window which
>> (I think) you really mean to eliminate.
>>
> Well, I certainly don't like the window to be there, and closing it
> would be ideal, IMO.
>
> However, in this patch, I'm addressing the specific situation of when
> we are stopping a timer for which an interrupt has already fired, the
> interrupt's ISR has already raised TIMER_SOFTIRQ, and yet we don't run
> the handler.
>
> Yes, if an interrupt is about to be raised, and/or it arrives _while_
> we are inside this function (after the check), or already in
> deactivate_timer(), we also end up not running the handler.
>
> I guess these can be seen as two aspects of the same problem, or as
> conceptually different issues, but whatever you consider them, getting
> rid of the former is something I consider an improvement.
It may be improvement, yes, but if there is
- no actual case breaking with the current code, I don't see
the need for the change,
- an actual case breaking with the current code, it'll still break
with the change as the window was merely shrunk.
>> Furthermore, taking both changes together: What if the same
>> you try to address in stop_timer() happens in set_timer()? Wouldn't
>> it then be only consistent to also require a timer even to fire for
>> the
>> old expiry value, before the new one is being set?
>>
> Yes, personally, I think that, whenever it is that we figure out that
> we missed handling a timer interrupt, we should run it then.
>
> Unfortunately, for achieving this, e.g., in the set_timer() case, I
> don't see much alternatives to call execute_timer() right in there. But
> that would violate the current invariant that execute_timer() only run
> from the TIMER_SOFTIRQ handler... which is probably doable, but is at
> the same time unrelated to the problem I'm tackling here, and I would
> rather do it in a dedicated series.
Indeed forcing the handler to run in the set_timer() case is more
difficult, yet as said - if there's a window to be concerned about,
the concern should be regarding all such windows, or none of
them imo.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/3] xen: RCU: make the period of the idle timer configurable.
>>> On 26.09.17 at 19:48, wrote:
> On Tue, 2017-09-26 at 09:14 -0600, Jan Beulich wrote:
>> > > > On 15.09.17 at 20:01, wrote:
>> > --- a/xen/common/rcupdate.c
>> > +++ b/xen/common/rcupdate.c
>> > +int ret = 0;
>> > +
>> > +if ( MILLISECS(period) > IDLE_TIMER_PERIOD_MAX )
>> > +{
>> > +printk("WARNING: rcu_idle_timer_period_ms must be <
>> > %"PRI_stime"\n",
>> > + IDLE_TIMER_PERIOD_MAX / MILLISECS(1));
>> > +ret = -EINVAL;
>> > +}
>> > +else
>> > +idle_timer_period = MILLISECS(period);
>> > +
>> > +printk("RCU idle timer period: %lums\n", period);
>> > +
>> > +return ret;
>> > +}
>> > +custom_param("rcu_idle_timer_period_ms", parse_idle_timer_period);
>>
>> Does this really need handling as custom_param(). I.e. wouldn't
>> integer_param() plus sanitizing in rcu_init() suffice?
>>
> I did it like that in the first place. But then I did not like the
> overall look of the patch, so I changed the approach.
>
> I can put it back together the integer_param() variant, and you'll tell
> me which one you like better.
>
>> That would
>> also make the log message be printed uniformly - merely echoing
>> the value from the command line doesn't look very useful to me.
>>
> Mmm.. Sorry, but I don't get this part.
In this version of the patch you log the message if and only if
the command line option was specified. This means that
- without command line option the log won't tell us anything
- with a valid command line option the log will tell us the same
thing twice (once via the logged command line, and another
time in the message you add)
- with an invalid command line option you'll be issuing both a
warning and the message reporting the used value
I can live with the new message duplicating the command line
information (i.e. there's no point in suppressing the new log
message if the command line option was used), but (a) there
shouldn't be two messages (or really three, as returning
-EINVAL will trigger another message in the caller) and (b) if
knowing the period of the timer is something you consider
worth logging, it should be logged even when there's no
command line option.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5] x86/hvm: Implement hvmemul_write() using real mappings
On 27/09/2017 09:04, Alexandru Isaila wrote:
> From: Andrew Cooper
>
> An access which crosses a page boundary is performed atomically by x86
> hardware, albeit with a severe performance penalty. An important corner case
> is when a straddled access hits two pages which differ in whether a
> translation exists, or in net access rights.
>
> The use of hvm_copy*() in hvmemul_write() is problematic, because it performs
> a translation then completes the partial write, before moving onto the next
> translation.
>
> If an individual emulated write straddles two pages, the first of which is
> writable, and the second of which is not, the first half of the write will
> complete before #PF is raised from the second half.
>
> This results in guest state corruption as a side effect of emulation, which
> has been observed to cause windows to crash while under introspection.
>
> Introduce the hvmemul_{,un}map_linear_addr() helpers, which translate an
> entire contents of a linear access, and vmap() the underlying frames to
> provide a contiguous virtual mapping for the emulator to use. This is the
> same mechanism as used by the shadow emulation code.
>
> This will catch any translation issues and abort the emulation before any
> modifications occur.
>
> Signed-off-by: Andrew Cooper
> Signed-off-by: Alexandru Isaila
>
> ---
> Changes since V4:
> - Moved the mfn increment line back
> - Removed the new line between mfn++ and while
>
> Reviewed-by: Paul Durrant
> ---
> xen/arch/x86/hvm/emulate.c| 174
> ++
> xen/include/asm-x86/hvm/emulate.h | 7 ++
> 2 files changed, 164 insertions(+), 17 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index cc874ce..9d8be30 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -498,6 +498,156 @@ static int hvmemul_do_mmio_addr(paddr_t mmio_gpa,
> }
>
> /*
> + * Map the frame(s) covering an individual linear access, for writeable
> + * access. May return NULL for MMIO, or ERR_PTR(~X86EMUL_*) for other errors
> + * including ERR_PTR(~X86EMUL_OKAY) for write-discard mappings.
> + *
> + * In debug builds, map() checks that each slot in hvmemul_ctxt->mfn[] is
> + * clean before use, and poisions unused slots with INVALID_MFN.
> + */
> +static void *hvmemul_map_linear_addr(
> +unsigned long linear, unsigned int bytes, uint32_t pfec,
> +struct hvm_emulate_ctxt *hvmemul_ctxt)
> +{
> +struct vcpu *curr = current;
> +void *err, *mapping;
> +
> +/* First and final gfns which need mapping. */
> +unsigned long frame = linear >> PAGE_SHIFT, first = frame;
> +unsigned long final = (linear + bytes - !!bytes) >> PAGE_SHIFT;
To function correctly for an access which spans the 4G or 64bit
boundary, I think you need:
if ( hvmemul_ctxt->ctxt.addr_size < 64 )
{
frame = (uint32_t)frame;
final = (uint32_t) final;
}
> +
> +/*
> + * mfn points to the next free slot. All used slots have a page
> reference
> + * held on them.
> + */
> +mfn_t *mfn = &hvmemul_ctxt->mfn[0];
> +
> +/*
> + * The caller has no legitimate reason for trying a zero-byte write, but
> + * final is calculate to fail safe in release builds.
> + *
> + * The maximum write size depends on the number of adjacent mfns[] which
> + * can be vmap()'d, accouting for possible misalignment within the
> region.
> + * The higher level emulation callers are responsible for ensuring that
> + * mfns[] is large enough for the requested write size.
> + */
> +if ( bytes == 0 ||
> + final - first >= ARRAY_SIZE(hvmemul_ctxt->mfn) )
> +{
> +ASSERT_UNREACHABLE();
> +goto unhandleable;
> +}
> +
> +do {
> +enum hvm_translation_result res;
> +struct page_info *page;
> +pagefault_info_t pfinfo;
> +p2m_type_t p2mt;
> +
> +/* Error checking. Confirm that the current slot is clean. */
> +ASSERT(mfn_x(*mfn) == 0);
> +
> +res = hvm_translate_get_page(curr, frame << PAGE_SHIFT, true, pfec,
> + &pfinfo, &page, NULL, &p2mt);
> +
> +switch ( res )
> +{
> +case HVMTRANS_okay:
> +break;
> +
> +case HVMTRANS_bad_linear_to_gfn:
> +x86_emul_pagefault(pfinfo.ec, pfinfo.linear,
> &hvmemul_ctxt->ctxt);
> +err = ERR_PTR(~X86EMUL_EXCEPTION);
> +goto out;
> +
> +case HVMTRANS_bad_gfn_to_mfn:
> +err = NULL;
> +goto out;
> +
> +case HVMTRANS_gfn_paged_out:
> +case HVMTRANS_gfn_shared:
> +err = ERR_PTR(~X86EMUL_RETRY);
> +goto out;
> +
> +default:
> +goto unhandleable;
> +}
> +
> +*mfn++ = _mfn(page_to_mfn(page));
> +
> +if ( p2m_is_discard_write(p2mt) )
> +{
> +err = ERR_PTR(~X86EMUL_OKAY);
> +goto out;
[Xen-devel] [linux-linus test] 113845: regressions - FAIL
flight 113845 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/113845/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 113823 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 113823 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail blocked in 113823 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 113823 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 113823 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 113823 test-amd64-amd64-xl-rtds 10 debian-install fail like 113823 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 113823 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 113823 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: linuxdc972a67cc54585bd83ad811c4e9b6ab3dcd427e baseline version: linuxe365806ac289457263a133bd32df8df49897f612 Last test of basis 113823 2017-09-26 08:36:21 Z0 days Testing same since 113845 2017-09-27 00:20:16 Z0 days1 attempts People who touched revisions under test: Adrian Hunter Andreas Gruenbacher Linus Torvalds Ulf Hansson Wolfram Sang jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt
Re: [Xen-devel] [PATCH] Call xen_cleanhighmap() with 4MB aligned for page tables mapping
On 27/09/17 05:03, Zhenzhong Duan wrote: > When bootup a PVM guest with large memory(Ex.240GB), XEN provided initial > mapping overlaps with kernel module virtual space. When mapping in this space > is cleared by xen_cleanhighmap(), in certain case there could be an 2MB > mapping > left. This is due to XEN initialize 4MB aligned mapping but xen_cleanhighmap() > finish at 2MB boundary. > > When module loading is just on top of the 2MB space, got below warning: > > WARNING: at mm/vmalloc.c:106 vmap_pte_range+0x14e/0x190() > Call Trace: > [] warn_alloc_failed+0xf3/0x160 > [] __vmalloc_area_node+0x182/0x1c0 > [] ? module_alloc_update_bounds+0x1e/0x80 > [] __vmalloc_node_range+0xa7/0x110 > [] ? module_alloc_update_bounds+0x1e/0x80 > [] module_alloc+0x64/0x70 > [] ? module_alloc_update_bounds+0x1e/0x80 > [] module_alloc_update_bounds+0x1e/0x80 > [] move_module+0x27/0x150 > [] layout_and_allocate+0x120/0x1b0 > [] load_module+0x78/0x640 > [] ? security_file_permission+0x8b/0x90 > [] sys_init_module+0x62/0x1e0 > [] system_call_fastpath+0x16/0x1b > > Then the mapping of 2MB is cleared, finally oops when the page in that space > is > accessed. > > BUG: unable to handle kernel paging request at 88002260 > IP: [] clear_page_c_e+0x7/0x10 > PGD 1788067 PUD 178c067 PMD 22434067 PTE 0 > Oops: 0002 [#1] SMP > Call Trace: > [] ? prep_new_page+0x127/0x1c0 > [] get_page_from_freelist+0x1e2/0x550 > [] ? ii_iovec_copy_to_user+0x90/0x140 > [] __alloc_pages_nodemask+0x12d/0x230 > [] alloc_pages_vma+0xc6/0x1a0 > [] ? pte_mfn_to_pfn+0x7d/0x100 > [] do_anonymous_page+0x16b/0x350 > [] handle_pte_fault+0x1e4/0x200 > [] ? xen_pmd_val+0xe/0x10 > [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e > [] handle_mm_fault+0x15b/0x270 > [] do_page_fault+0x140/0x470 > [] page_fault+0x25/0x30 > > Call xen_cleanhighmap() with 4MB aligned for page tables mapping to fix it. > The unnecessory call of xen_cleanhighmap() in DEBUG mode is also removed. > > References: > https://lists.xen.org/archives/html/xen-devel/2012-07/msg01562.html > Signed-off-by: Zhenzhong Duan > --- > arch/x86/xen/mmu_pv.c | 12 +++- > 1 files changed, 3 insertions(+), 9 deletions(-) > > diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c > index 7330cb3..3628d97 100644 > --- a/arch/x86/xen/mmu_pv.c > +++ b/arch/x86/xen/mmu_pv.c > @@ -1238,21 +1238,15 @@ static void __init xen_pagetable_cleanhighmap(void) >* from _brk_limit way up to the max_pfn_mapped (which is the end of >* the ramdisk). We continue on, erasing PMD entries that point to page >* tables - do note that they are accessible at this stage via __va. > - * For good measure we also round up to the PMD - which means that if > + * For good measure we also round up to the PMD*2 - which means that if Could you please add in the comment that Xen is aligning the memory end to a 4MB boundary? >* anybody is using __ka address to the initial boot-stack - and try >* to use it - they are going to crash. The xen_start_info has been >* taken care of already in xen_setup_kernel_pagetable. */ > addr = xen_start_info->pt_base; > - size = roundup(xen_start_info->nr_pt_frames * PAGE_SIZE, PMD_SIZE); > + size = xen_start_info->nr_pt_frames * PAGE_SIZE; > > - xen_cleanhighmap(addr, addr + size); > + xen_cleanhighmap(addr, roundup(addr + size, PMD_SIZE*2)); Coding style: please use "PMD_SIZE * 2". Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 113847: all pass - PUSHED
flight 113847 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113847/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cbd7300c802d4a855991c041527d621717a984d2
baseline version:
ovmf f724f9d9c72aa235d50eaa51b1a4e3508ebf1364
Last test of basis 113841 2017-09-26 22:49:31 Z0 days
Testing same since 113847 2017-09-27 02:08:21 Z0 days1 attempts
People who touched revisions under test:
Dandan Bi
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=cbd7300c802d4a855991c041527d621717a984d2
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
export PERLLIB=.:.
PERLLIB=.:.
+++ 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
cbd7300c802d4a855991c041527d621717a984d2
+ branch=ovmf
+ revision=cbd7300c802d4a855991c041527d621717a984d2
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
export PERLLIB=.:.:.
PERLLIB=.:.:.
+++ 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
+++ export PERLLIB=.:.:.:.
+++ PERLLIB=.:.:.:.
++ 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.9-testing
+ '[' xcbd7300c802d4a855991c041527d621717a984d2 = 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
++
Re: [Xen-devel] [PATCH v5] x86/hvm: Implement hvmemul_write() using real mappings
>>> On 27.09.17 at 10:38, wrote:
> On 27/09/2017 09:04, Alexandru Isaila wrote:
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -498,6 +498,156 @@ static int hvmemul_do_mmio_addr(paddr_t mmio_gpa,
>> }
>>
>> /*
>> + * Map the frame(s) covering an individual linear access, for writeable
>> + * access. May return NULL for MMIO, or ERR_PTR(~X86EMUL_*) for other
>> errors
>> + * including ERR_PTR(~X86EMUL_OKAY) for write-discard mappings.
>> + *
>> + * In debug builds, map() checks that each slot in hvmemul_ctxt->mfn[] is
>> + * clean before use, and poisions unused slots with INVALID_MFN.
>> + */
>> +static void *hvmemul_map_linear_addr(
>> +unsigned long linear, unsigned int bytes, uint32_t pfec,
>> +struct hvm_emulate_ctxt *hvmemul_ctxt)
>> +{
>> +struct vcpu *curr = current;
>> +void *err, *mapping;
>> +
>> +/* First and final gfns which need mapping. */
>> +unsigned long frame = linear >> PAGE_SHIFT, first = frame;
>> +unsigned long final = (linear + bytes - !!bytes) >> PAGE_SHIFT;
>
> To function correctly for an access which spans the 4G or 64bit
> boundary, I think you need:
>
> if ( hvmemul_ctxt->ctxt.addr_size < 64 )
> {
> frame = (uint32_t)frame;
> final = (uint32_t) final;
> }
>> +
>> +/*
>> + * mfn points to the next free slot. All used slots have a page
>> reference
>> + * held on them.
>> + */
>> +mfn_t *mfn = &hvmemul_ctxt->mfn[0];
>> +
>> +/*
>> + * The caller has no legitimate reason for trying a zero-byte write, but
>> + * final is calculate to fail safe in release builds.
>> + *
>> + * The maximum write size depends on the number of adjacent mfns[] which
>> + * can be vmap()'d, accouting for possible misalignment within the
>> region.
>> + * The higher level emulation callers are responsible for ensuring that
>> + * mfns[] is large enough for the requested write size.
>> + */
>> +if ( bytes == 0 ||
>> + final - first >= ARRAY_SIZE(hvmemul_ctxt->mfn) )
Taking wrapping into account, this also isn't right, and hence may
need restoring to its original (slightly more involved) form.
>> +{
>> +ASSERT_UNREACHABLE();
>> +goto unhandleable;
>> +}
>> +
>> +do {
>> +enum hvm_translation_result res;
>> +struct page_info *page;
>> +pagefault_info_t pfinfo;
>> +p2m_type_t p2mt;
>> +
>> +/* Error checking. Confirm that the current slot is clean. */
>> +ASSERT(mfn_x(*mfn) == 0);
>> +
>> +res = hvm_translate_get_page(curr, frame << PAGE_SHIFT, true, pfec,
>> + &pfinfo, &page, NULL, &p2mt);
>> +
>> +switch ( res )
>> +{
>> +case HVMTRANS_okay:
>> +break;
>> +
>> +case HVMTRANS_bad_linear_to_gfn:
>> +x86_emul_pagefault(pfinfo.ec, pfinfo.linear,
>> &hvmemul_ctxt->ctxt);
>> +err = ERR_PTR(~X86EMUL_EXCEPTION);
>> +goto out;
>> +
>> +case HVMTRANS_bad_gfn_to_mfn:
>> +err = NULL;
>> +goto out;
>> +
>> +case HVMTRANS_gfn_paged_out:
>> +case HVMTRANS_gfn_shared:
>> +err = ERR_PTR(~X86EMUL_RETRY);
>> +goto out;
>> +
>> +default:
>> +goto unhandleable;
>> +}
>> +
>> +*mfn++ = _mfn(page_to_mfn(page));
>> +
>> +if ( p2m_is_discard_write(p2mt) )
>> +{
>> +err = ERR_PTR(~X86EMUL_OKAY);
>> +goto out;
>> +}
>> +
>> +} while ( ++frame < final );
>
> frame != final
This would still be wrong if final < frame, as the increment won't
wrap. I.e. clipping to 52/20 bits would be needed after the increment
(which in turn will make it better for the increment to again happen
inside the loop rather than in the while()).
>> +/* Entire access within a single frame? */
>> +if ( first == final )
>> +mapping = map_domain_page(hvmemul_ctxt->mfn[0]);
>> +/* Multiple frames? Need to vmap(). */
>> +else if ( (mapping = vmap(hvmemul_ctxt->mfn,
>> + final - first + 1)) == NULL )
Same issue here as mentioned above. Perhaps easier to have a
local variable counting the number of pages?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] Call xen_cleanhighmap() with 4MB aligned for page tables mapping
When bootup a PVM guest with large memory(Ex.240GB), XEN provided initial mapping overlaps with kernel module virtual space. When mapping in this space is cleared by xen_cleanhighmap(), in certain case there could be an 2MB mapping left. This is due to XEN initialize 4MB aligned mapping but xen_cleanhighmap() finish at 2MB boundary. When module loading is just on top of the 2MB space, got below warning: WARNING: at mm/vmalloc.c:106 vmap_pte_range+0x14e/0x190() Call Trace: [] warn_alloc_failed+0xf3/0x160 [] __vmalloc_area_node+0x182/0x1c0 [] ? module_alloc_update_bounds+0x1e/0x80 [] __vmalloc_node_range+0xa7/0x110 [] ? module_alloc_update_bounds+0x1e/0x80 [] module_alloc+0x64/0x70 [] ? module_alloc_update_bounds+0x1e/0x80 [] module_alloc_update_bounds+0x1e/0x80 [] move_module+0x27/0x150 [] layout_and_allocate+0x120/0x1b0 [] load_module+0x78/0x640 [] ? security_file_permission+0x8b/0x90 [] sys_init_module+0x62/0x1e0 [] system_call_fastpath+0x16/0x1b Then the mapping of 2MB is cleared, finally oops when the page in that space is accessed. BUG: unable to handle kernel paging request at 88002260 IP: [] clear_page_c_e+0x7/0x10 PGD 1788067 PUD 178c067 PMD 22434067 PTE 0 Oops: 0002 [#1] SMP Call Trace: [] ? prep_new_page+0x127/0x1c0 [] get_page_from_freelist+0x1e2/0x550 [] ? ii_iovec_copy_to_user+0x90/0x140 [] __alloc_pages_nodemask+0x12d/0x230 [] alloc_pages_vma+0xc6/0x1a0 [] ? pte_mfn_to_pfn+0x7d/0x100 [] do_anonymous_page+0x16b/0x350 [] handle_pte_fault+0x1e4/0x200 [] ? xen_pmd_val+0xe/0x10 [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e [] handle_mm_fault+0x15b/0x270 [] do_page_fault+0x140/0x470 [] page_fault+0x25/0x30 Call xen_cleanhighmap() with 4MB aligned for page tables mapping to fix it. The unnecessory call of xen_cleanhighmap() in DEBUG mode is also removed. -v2: add comment about XEN alignment from Juergen. References: https://lists.xen.org/archives/html/xen-devel/2012-07/msg01562.html Signed-off-by: Zhenzhong Duan --- arch/x86/xen/mmu_pv.c | 13 - 1 files changed, 4 insertions(+), 9 deletions(-) diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c index 7330cb3..aa0f7e2 100644 --- a/arch/x86/xen/mmu_pv.c +++ b/arch/x86/xen/mmu_pv.c @@ -1238,21 +1238,16 @@ static void __init xen_pagetable_cleanhighmap(void) * from _brk_limit way up to the max_pfn_mapped (which is the end of * the ramdisk). We continue on, erasing PMD entries that point to page * tables - do note that they are accessible at this stage via __va. -* For good measure we also round up to the PMD - which means that if +* As Xen is aligning the memory end to a 4MB boundary, for good +* measure we also round up to PMD_SIZE * 2 - which means that if * anybody is using __ka address to the initial boot-stack - and try * to use it - they are going to crash. The xen_start_info has been * taken care of already in xen_setup_kernel_pagetable. */ addr = xen_start_info->pt_base; - size = roundup(xen_start_info->nr_pt_frames * PAGE_SIZE, PMD_SIZE); + size = xen_start_info->nr_pt_frames * PAGE_SIZE; - xen_cleanhighmap(addr, addr + size); + xen_cleanhighmap(addr, roundup(addr + size, PMD_SIZE * 2)); xen_start_info->pt_base = (unsigned long)__va(__pa(xen_start_info->pt_base)); -#ifdef DEBUG - /* This is superfluous and is not necessary, but you know what -* lets do it. The MODULES_VADDR -> MODULES_END should be clear of -* anything at this stage. */ - xen_cleanhighmap(MODULES_VADDR, roundup(MODULES_VADDR, PUD_SIZE) - 1); -#endif } #endif -- 1.7.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] Call xen_cleanhighmap() with 4MB aligned for page tables mapping
On 27/09/17 11:41, Zhenzhong Duan wrote: > When bootup a PVM guest with large memory(Ex.240GB), XEN provided initial > mapping overlaps with kernel module virtual space. When mapping in this space > is cleared by xen_cleanhighmap(), in certain case there could be an 2MB > mapping > left. This is due to XEN initialize 4MB aligned mapping but xen_cleanhighmap() > finish at 2MB boundary. > > When module loading is just on top of the 2MB space, got below warning: > > WARNING: at mm/vmalloc.c:106 vmap_pte_range+0x14e/0x190() > Call Trace: > [] warn_alloc_failed+0xf3/0x160 > [] __vmalloc_area_node+0x182/0x1c0 > [] ? module_alloc_update_bounds+0x1e/0x80 > [] __vmalloc_node_range+0xa7/0x110 > [] ? module_alloc_update_bounds+0x1e/0x80 > [] module_alloc+0x64/0x70 > [] ? module_alloc_update_bounds+0x1e/0x80 > [] module_alloc_update_bounds+0x1e/0x80 > [] move_module+0x27/0x150 > [] layout_and_allocate+0x120/0x1b0 > [] load_module+0x78/0x640 > [] ? security_file_permission+0x8b/0x90 > [] sys_init_module+0x62/0x1e0 > [] system_call_fastpath+0x16/0x1b > > Then the mapping of 2MB is cleared, finally oops when the page in that space > is > accessed. > > BUG: unable to handle kernel paging request at 88002260 > IP: [] clear_page_c_e+0x7/0x10 > PGD 1788067 PUD 178c067 PMD 22434067 PTE 0 > Oops: 0002 [#1] SMP > Call Trace: > [] ? prep_new_page+0x127/0x1c0 > [] get_page_from_freelist+0x1e2/0x550 > [] ? ii_iovec_copy_to_user+0x90/0x140 > [] __alloc_pages_nodemask+0x12d/0x230 > [] alloc_pages_vma+0xc6/0x1a0 > [] ? pte_mfn_to_pfn+0x7d/0x100 > [] do_anonymous_page+0x16b/0x350 > [] handle_pte_fault+0x1e4/0x200 > [] ? xen_pmd_val+0xe/0x10 > [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e > [] handle_mm_fault+0x15b/0x270 > [] do_page_fault+0x140/0x470 > [] page_fault+0x25/0x30 > > Call xen_cleanhighmap() with 4MB aligned for page tables mapping to fix it. > The unnecessory call of xen_cleanhighmap() in DEBUG mode is also removed. > > -v2: add comment about XEN alignment from Juergen. > > References: > https://lists.xen.org/archives/html/xen-devel/2012-07/msg01562.html > Signed-off-by: Zhenzhong Duan Reviewed-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH] ts-leak-check: Treat listing failure as fail, not broken
This can easily occur if the test host crashes, due to a bug.
Signed-off-by: Ian Jackson
---
ts-leak-check | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ts-leak-check b/ts-leak-check
index 7dbabfe..678d069 100755
--- a/ts-leak-check
+++ b/ts-leak-check
@@ -176,7 +176,7 @@ if (!eval {
&{ "finish_$mode" }();
1;
}) {
-broken("listing/checking leakable objects: $@");
+fail("listing/checking leakable objects: $@");
}
fail("$leaks leaked object(s)") if $leaks;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] xen: timers: don't miss a timer event because of stop_timer()
On Wed, 2017-09-27 at 02:20 -0600, Jan Beulich wrote:
> > > > On 26.09.17 at 20:11, wrote:
> > it means there is an event that *is* in progress right now (i.e.,
> > we're
> > stopping the timer on the path that goes from the interrupt that
> > raised
> > TIMER_SOFTIRQ, and the timer softirq handler).
> >
> > So, basically, I'm trying to achieve exactly what you call
> > reasonable:
> > servicing an event which is in progress. :-)
>
> I'm afraid I don't understand - if the processing of the timer is
> already in progress, why would you need to raise another
> softirq? Wouldn't it suffice to simply skip deactivate_timer() then?
>
Ah, yes! In the use case I'm trying to fix, that's indeed not
necessary, as it has already been risen.
Basically, as it's harmless to re-raise it, I thought to do so, with
the aim of making it easier to understand what the code was trying to
achieve. But now I actually agree with you that the effect is quite the
opposite. :-(
I will get rid of the re-raising, and explain the situation better in
the both the comment and the changelog.
> This raising of the softirq is what made me imply that, perhaps
> due to some minimal skew e.g. resulting from rounding, you
> assume the interrupt did not fire yet, which I'd then call the
> timer event not being in progress (yet).
>
Sure, I totally see it now, and I also totally agree.
> In the end what I think I'm missing is a clear description of an
> actual
> case where the current behavior causes breakage (plus of course
> an explanation why the new behavior is unlikely to cause issues with
> existing users).
>
So, the problem is that the handler of the RCU idle_timer, introduced
by 2b936ea7b716dc1a13c ("xen: RCU: avoid busy waiting until the end of
grace period."), never runs.
And that is because the following happens:
- the CPU wants to go idle
- sched_tick_suspend()
rcu_idle_timer_start()
set_timer(RCU_idle_timer)
- the CPU goes idle
... ... ...
- RCU_idle_timer's IRQ arrives
- the CPU wakes up
- raise_softirq(TIMER_SOFTIRQ)
- sched_tick_resume()
rcu_idle_timer_stop()
stop_timer(RCU_idle_timer)
deactivate_timer(RCU_idle_timer)
remove_entry(RCU_idle_timer) // timer out of heap/list
- do_softirq() (we are inside idle_loop())
- softirq_handlers[TIMER_SOFTIRQ]()
- timer_softirq_action()
// but the timer is not in the heap/list!
Now, as far as the purpose of that patch goes, we're fine. In fact,
there, we "only" needed to avoid that a certain CPU (because of its
role in the grace period) would sleep too long/indefinitely. And the
fact that the CPU does wake up, because of the timer interrupt, is
enough.
However, it's been asked to try to make the logic a bit more clever,
basically for preventing RCU_idle_timer from firing too often. And
that's actually what this series is doing. But now, in order to achieve
that, I do need the timer handler to run.
About the (lack of) breakage of existing use cases. Well, hard to tell
like this, but I'd say that, if, right now, we are not missing any
timer event handling, it means that this situation --where you stop the
timer in between raise_softirq(TIMER_SOFTIRQ) and
softirq_handler[TIMER_SOFTIRQ]()-- never happens.
Inspecting the code, in fact, I can't spot any stop_timer() happening
within that window, which I think it means we're fine (IOW,
RCU_idle_timer is the first, and for now only, timer that is stopped on
the CPU wake-up-from-idle path).
It is important (in the new version of this patch) for deactivation to
be skipped only in stop_timer(), and not, e.g., in kill_timer(). As, if
someone, in future, will want to kill and free the timer during the
window, then in that case the handler *must* not run.
Makes sense?
Thanks and Regards,
Dario
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] xen: timers: don't miss a timer event because of stop_timer()
>>> On 27.09.17 at 12:18, wrote:
> On Wed, 2017-09-27 at 02:20 -0600, Jan Beulich wrote:
>> In the end what I think I'm missing is a clear description of an
>> actual
>> case where the current behavior causes breakage (plus of course
>> an explanation why the new behavior is unlikely to cause issues with
>> existing users).
>>
> So, the problem is that the handler of the RCU idle_timer, introduced
> by 2b936ea7b716dc1a13c ("xen: RCU: avoid busy waiting until the end of
> grace period."), never runs.
>
> And that is because the following happens:
> - the CPU wants to go idle
> - sched_tick_suspend()
> rcu_idle_timer_start()
> set_timer(RCU_idle_timer)
> - the CPU goes idle
> ... ... ...
> - RCU_idle_timer's IRQ arrives
> - the CPU wakes up
> - raise_softirq(TIMER_SOFTIRQ)
> - sched_tick_resume()
> rcu_idle_timer_stop()
> stop_timer(RCU_idle_timer)
> deactivate_timer(RCU_idle_timer)
> remove_entry(RCU_idle_timer) // timer out of heap/list
> - do_softirq() (we are inside idle_loop())
> - softirq_handlers[TIMER_SOFTIRQ]()
> - timer_softirq_action()
> // but the timer is not in the heap/list!
But this is an extremely special case, not something likely to
happen anywhere else. Hence I wonder whether it wouldn't
be better to handle the special case in a special way, rather
than making generic code fit the special case. Or wait -
wouldn't all you need be to avoid calling stop_timer() in the
call tree above, if the timer's expiry has passed (suitably
explained in a comment)?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-coverity test] 113858: all pass - PUSHED
flight 113858 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113858/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen a8ea6e2688118a3e19e29b39e316faa5f96ab9d1
baseline version:
xen 7ff9661b904a3af618dc2a2b8cdec46be6930308
Last test of basis 113792 2017-09-24 09:18:45 Z3 days
Testing same since 113858 2017-09-27 09:32:23 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Anthony PERARD
Dario Faggioli
Euan Harris
George Dunlap
Jan Beulich
Jennifer Herbert
Joshua Otto
Marek Marczykowski-Górecki
Paul Durrant
Sergey Dyasli
Wei Liu
jobs:
coverity-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=xen-unstable-coverity
+ revision=a8ea6e2688118a3e19e29b39e316faa5f96ab9d1
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
export PERLLIB=.:.
PERLLIB=.:.
+++ 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-coverity a8ea6e2688118a3e19e29b39e316faa5f96ab9d1
+ branch=xen-unstable-coverity
+ revision=a8ea6e2688118a3e19e29b39e316faa5f96ab9d1
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
export PERLLIB=.:.:.
PERLLIB=.:.:.
+++ 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
+++ export PERLLIB=.:.:.:.
+++ PERLLIB=.:.:.:.
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-coverity
+ qemuubranch=qemu-upstream-unstable-coverity
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-coverity
+ prevxenbranch=xen-4.9-testing
+ '[' xa8ea6e2688118a3e19e29b39e316faa5f96ab9d1 = 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.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-4.9
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x =
[Xen-devel] [OSSTEST PATCH] ts-kernel-build: enable ntfs and fuse support
They will be useful for extracting files from Windows and other OSes from Dom0 while debugging. Signed-off-by: Wei Liu --- ts-kernel-build | 5 + 1 file changed, 5 insertions(+) diff --git a/ts-kernel-build b/ts-kernel-build index 22a027a..5f152a3 100755 --- a/ts-kernel-build +++ b/ts-kernel-build @@ -200,6 +200,11 @@ setopt CONFIG_EXT4_FS m setopt CONFIG_UFS_FS m setopt CONFIG_UFS_FS_WRITE y +setopt CONFIG_NTFS_FS m +setopt CONFIG_NTFS_RW y + +setopt CONFIG_FUSE_FS m + setopt CONFIG_BLK_DEV_NBD y # At least with Linux 3.4.77 on wheezy, the nbd module is # not loaded automatically. -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 01/12] x86/mm: allow a privileged PV domain to map guest mfns
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 25 September 2017 14:03
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v7 01/12] x86/mm: allow a privileged PV domain to map
> guest mfns
>
> >>> On 18.09.17 at 17:31, wrote:
> > In the case where a PV domain is mapping guest resources then it needs
> make
> > the HYPERVISOR_mmu_update call using DOMID_SELF, rather than the
> guest
> > domid, so that the passed in gmfn values are correctly treated as mfns
> > rather than gfns present in the guest p2m.
>
> Since things are presently working fine, I think the description is not
> really accurate. You only require the new behavior if you don't know
> the GFN of the page you want to map, and that it has to be
> DOMID_SELF that should be passed also doesn't appear to derive
> from anything else. To properly judge about the need for this patch
> it would help if it was briefly explained why being able to map by GFN
> is no longer sufficient, and to re-word the DOMID_SELF part.
>
> The other aspect I don't understand is why this is needed for PV
> Dom0, but not for PVH. The answer here can't be "because PVH
> Dom0 isn't supported yet", because it eventually will be, and then
> there will still be the problem of PVH supposedly having no notion
> of MFNs (be their own or foreign guest ones). The answer also
> can't be "since it would use XENMAPSPACE_gmfn_foreign", as
> that's acting in terms of GFN too.
>
> > This patch removes a check which currently disallows mapping of a page
> when
> > the owner of the page tables matches the domain passed to
> > HYPERVISOR_mmu_update, but that domain is not the real owner of the
> page.
> > The check was introduced by patch d3c6a215ca9 ("x86: Clean up
> > get_page_from_l1e() to correctly distinguish between owner-of-pte and
> > owner-of-data-page in all cases") but it's not clear why it was needed.
>
> I think the goal here simply was to not permit anything that doesn't
> really need permitting. Furthermore the check being "introduced"
> there was, afaict, replacing the earlier d != curr->domain.
>
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -1024,12 +1024,15 @@ get_page_from_l1e(
> > (real_pg_owner != dom_cow) ) )
> > {
> > /*
> > - * Let privileged domains transfer the right to map their target
> > - * domain's pages. This is used to allow stub-domain pvfb export to
> > - * dom0, until pvfb supports granted mappings. At that time this
> > - * minor hack can go away.
> > + * If the real page owner is not the domain specified in the
> > + * hypercall then establish that the specified domain has
> > + * mapping privilege over the page owner.
> > + * This is used to allow stub-domain pvfb export to dom0. It is
> > + * also used to allow a privileged PV domain to map mfns using
> > + * DOMID_SELF, which is needed for mapping guest resources such
> > + * grant table frames.
>
> How do grant table frames come into the picture here? So far
> I had assumed only ioreq server pages are in need of this.
>
> > */
> > -if ( (real_pg_owner == NULL) || (pg_owner == l1e_owner) ||
> > +if ( (real_pg_owner == NULL) ||
> > xsm_priv_mapping(XSM_TARGET, pg_owner, real_pg_owner) )
> > {
> > gdprintk(XENLOG_WARNING,
>
> I'm concerned of the effect of the change on the code paths
> which you're not really interested in: alloc_l1_table(),
> ptwr_emulated_update(), and shadow_get_page_from_l1e() all
> explicitly pass both domains identical, and are now suddenly able
> to do things they weren't supposed to do. A similar concern
> applies to __do_update_va_mapping() calling mod_l1_table().
>
> I therefore wonder whether the solution to your problem
> wouldn't rather be MMU_FOREIGN_PT_UPDATE (name subject
> to improvement suggestions). This at the same time would
> address my concern regarding the misleading DOMID_SELF
> passing when really a foreign domain's page is meant.
Looking at this I wonder whether a cleaner solution would be to introduce a new
domid: DOMID_ANY. This meaning of this would be along the same sort of lines as
DOMID_XEN or DOMID_IO and would be used in mmu_update to mean 'any page over
which the caller has privilege'. Does that sound reasonable?
Paul
>
> Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 113851: tolerable all pass - PUSHED
flight 113851 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113851/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 113821
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 113821
test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 113821
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass
test-amd64-i386-libvirt 13 migrate-support-checkfail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check
fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check
fail never pass
test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass
test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass
version targeted for testing:
libvirt 01f86fb301a55c15c33dd02e6a7e2aac5ecad93d
baseline version:
libvirt 93575f345116fe1413f6fe3109227b8be2f416da
Last test of basis 113821 2017-09-26 04:24:17 Z1 days
Testing same since 113851 2017-09-27 04:20:16 Z0 days1 attempts
People who touched revisions under test:
Ján Tomko
Peter Krempa
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-armhf-pvopspass
build-i386-pvops pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-libvirt-pairpass
test-amd64-i386-libvirt-pair pass
test-amd64-i386-libvirt-qcow2pass
test-armhf-armhf-libvirt-raw pass
test-amd64-amd64-libvirt-vhd 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=libvirt
+ revision=01f86fb301a55c15c33dd02e6a7e2aac5ecad93d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
export PERLLIB=.:.
PERLLIB=.:.
+++ 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 libvirt
01f86fb301a55c15c33dd02e6a7e2aac5ecad93d
+ branch=libvirt
+ revision=01f86fb301a55c15c33dd02e6a7e2aac5ecad93d
+ . ./cri-lock-re
Re: [Xen-devel] [PATCH v7 02/12] x86/mm: add HYPERVISOR_memory_op to acquire guest resources
On 26/09/17 13:49, Paul Durrant wrote: >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 26 September 2017 13:35 >> To: Andrew Cooper ; Paul Durrant >> >> Cc: xen-de...@lists.xenproject.org >> Subject: RE: [PATCH v7 02/12] x86/mm: add HYPERVISOR_memory_op to >> acquire guest resources >> > On 26.09.17 at 14:20, wrote: -Original Message- From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Paul Durrant Sent: 25 September 2017 16:00 To: 'Jan Beulich' Cc: Andrew Cooper ; xen- de...@lists.xenproject.org Subject: Re: [Xen-devel] [PATCH v7 02/12] x86/mm: add HYPERVISOR_memory_op to acquire guest resources > -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 25 September 2017 15:23 > To: Paul Durrant > Cc: Andrew Cooper ; xen- > de...@lists.xenproject.org > Subject: Re: [PATCH v7 02/12] x86/mm: add HYPERVISOR_memory_op >> to > acquire guest resources > On 18.09.17 at 17:31, wrote: >> Certain memory resources associated with a guest are not necessarily >> present in the guest P2M and so are not necessarily available to be >> foreign-mapped by a tools domain unless they are inserted, which >> risks >> shattering a super-page mapping. > Btw., I'm additionally having trouble seeing this shattering of a > superpage: For one, xc_core_arch_get_scratch_gpfn() could be > a little less simplistic. And then even with the currently chosen > value (outside of the range of valid GFNs at that point in time) > there shouldn't be a larger page to be shattered, as there should > be no mapping at all at that index. But perhaps I'm just blind and > don't see the obvious ... The shattering was Andrew's observation. Andrew, can you comment? >>> Andrew commented verbally on this. It's not actually a shattering as such... >>> The issue, apparently, is that adding the 4k grant table frame into the >>> guest >>> p2m will potentially cause creation of all layers of page table but removing >>> it again will only remove the L1 entry. Thus it is no longer possible to use >>> a superpage for that mapping at any point subsequently. >> First of all - what would cause a mapping to appear at that slot (or in >> a range covering that slot). ??? At the moment, the toolstack's *only* way of editing the grant table of an HVM guest is to add it into the p2m, map the gfn, write two values, and unmap it. That is how a 4k mapping gets added, which forces an allocation or shattering to cause a L1 table to exist. This is a kludge and is architecturally unclean. >> And then, while re-combining contiguous >> mappings indeed doesn't exist right now, replacing a non-leaf entry >> (page table) with a large page is very well supported (see e.g. >> ept_set_entry(), which even has a comment to that effect). I don't see anything equivalent in the NPT or IOMMU logic. >> Hence >> I continue to be confused why we need a new mechanism for >> seeding the grant tables. > I'll have to defer to Andrew to answer at this point. Joao's improvements for network transmit require a trusted backend to be able to map the full grant table. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/2] Coverity issues for credit2 CAP series
Wei Liu (2): xen/credit2: add missing unlock python/libxc: extend the call to get/set cap for credit2 tools/python/xen/lowlevel/xc/xc.c | 17 ++--- xen/common/sched_credit2.c| 1 + 2 files changed, 11 insertions(+), 7 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] python/libxc: extend the call to get/set cap for credit2
Commit 68817024 ("xen: credit2: allow to set and get utilization cap")
added a new parameter. Implement it for the python binding as well.
Coverity-ID: 1418532
Signed-off-by: Wei Liu
---
Cc: George Dunlap
Cc: Dario Faggioli
Cc: Marek Marczykowski-Górecki
Compile-test only.
---
tools/python/xen/lowlevel/xc/xc.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/tools/python/xen/lowlevel/xc/xc.c
b/tools/python/xen/lowlevel/xc/xc.c
index aa9f8e4d9e..f501764100 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -1348,16 +1348,19 @@ static PyObject *pyxc_sched_credit2_domain_set(XcObject
*self,
{
uint32_t domid;
uint16_t weight;
-static char *kwd_list[] = { "domid", "weight", NULL };
-static char kwd_type[] = "I|H";
-struct xen_domctl_sched_credit2 sdom;
+uint16_t cap;
+static char *kwd_list[] = { "domid", "weight", "cap", NULL };
+static char kwd_type[] = "I|HH";
+struct xen_domctl_sched_credit2 sdom = { };
weight = 0;
+cap = 0;
if( !PyArg_ParseTupleAndKeywords(args, kwds, kwd_type, kwd_list,
- &domid, &weight) )
+ &domid, &weight, &cap) )
return NULL;
sdom.weight = weight;
+sdom.cap = cap;
if ( xc_sched_credit2_domain_set(self->xc_handle, domid, &sdom) != 0 )
return pyxc_error_to_exception(self->xc_handle);
@@ -1369,7 +1372,7 @@ static PyObject *pyxc_sched_credit2_domain_set(XcObject
*self,
static PyObject *pyxc_sched_credit2_domain_get(XcObject *self, PyObject *args)
{
uint32_t domid;
-struct xen_domctl_sched_credit2 sdom;
+struct xen_domctl_sched_credit2 sdom = { };
if( !PyArg_ParseTuple(args, "I", &domid) )
return NULL;
@@ -1377,8 +1380,8 @@ static PyObject *pyxc_sched_credit2_domain_get(XcObject
*self, PyObject *args)
if ( xc_sched_credit2_domain_get(self->xc_handle, domid, &sdom) != 0 )
return pyxc_error_to_exception(self->xc_handle);
-return Py_BuildValue("{s:H}",
- "weight", sdom.weight);
+return Py_BuildValue("{s:HH}",
+ "weight", "cap", sdom.weight, sdom.cap);
}
static PyObject *pyxc_domain_setmaxmem(XcObject *self, PyObject *args)
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] xen/credit2: add missing unlock
Coverity-ID: 1418531
Signed-off-by: Wei Liu
---
Cc: George Dunlap
Cc: Dario Faggioli
---
xen/common/sched_credit2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index d33c881c3d..18f39cafe4 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -2831,6 +2831,7 @@ csched2_dom_cntl(
if ( op->u.credit2.cap > 100 * sdom->nr_vcpus )
{
rc = -EINVAL;
+write_unlock_irqrestore(&prv->lock, flags);
break;
}
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5] x86/hvm: Implement hvmemul_write() using real mappings
On Mi, 2017-09-27 at 09:38 +0100, Andrew Cooper wrote: > On 27/09/2017 09:04, Alexandru Isaila wrote: > > > > From: Andrew Cooper > > > > > > -return X86EMUL_EXCEPTION; > > -case HVMTRANS_bad_gfn_to_mfn: > > -return hvmemul_linear_mmio_write(addr, bytes, p_data, > > pfec, hvmemul_ctxt, 0); > Where has the if ( !mapping ) test gone? The HVMTRANS_bad_gfn_to_mfn > case needs handling. There was a comment form Jan in V2. NOTE: "v1 comment:'Pointless"else".'" This email was scanned by Bitdefender ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 1/3] x86/pvclock: add setter for pvclock_pvti_cpu0_va
Right now there is only a pvclock_pvti_cpu0_va() which is defined
on kvmclock since:
commit dac16fba6fc5
("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap")
The only user of this interface so far is kvm. This commit adds a
setter function for the pvti page and moves pvclock_pvti_cpu0_va
to pvclock, which is a more generic place to have it; and would
allow other PV clocksources to use it, such as Xen.
Signed-off-by: Joao Martins
Acked-by: Andy Lutomirski
---
Changes since v1:
* Rebased: the only conflict was that I had move the export
pvclock_pvti_cpu0_va() symbol as it is used by kvm PTP driver.
* Do not initialize pvti_cpu0_va to NULL (checkpatch error)
( Comments from Andy Lutomirski )
* Removed asm/pvclock.h 'pvclock_set_pvti_cpu0_va' definition
for non !PARAVIRT_CLOCK to better track screwed Kconfig stuff.
* Add his Acked-by (provided the previous adjustment was made)
Changes since RFC:
(Comments from Andy Lutomirski)
* Add __init to pvclock_set_pvti_cpu0_va
* Add WARN_ON(vclock_was_used(VCLOCK_PVCLOCK)) to
pvclock_set_pvti_cpu0_va
---
arch/x86/include/asm/pvclock.h | 19 ++-
arch/x86/kernel/kvmclock.c | 7 +--
arch/x86/kernel/pvclock.c | 14 ++
3 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
index 448cfe1b48cf..6f228f90cdd7 100644
--- a/arch/x86/include/asm/pvclock.h
+++ b/arch/x86/include/asm/pvclock.h
@@ -4,15 +4,6 @@
#include
#include
-#ifdef CONFIG_KVM_GUEST
-extern struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void);
-#else
-static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
-{
- return NULL;
-}
-#endif
-
/* some helper functions for xen and kvm pv clock sources */
u64 pvclock_clocksource_read(struct pvclock_vcpu_time_info *src);
u8 pvclock_read_flags(struct pvclock_vcpu_time_info *src);
@@ -101,4 +92,14 @@ struct pvclock_vsyscall_time_info {
#define PVTI_SIZE sizeof(struct pvclock_vsyscall_time_info)
+#ifdef CONFIG_PARAVIRT_CLOCK
+void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti);
+struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void);
+#else
+static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
+{
+ return NULL;
+}
+#endif
+
#endif /* _ASM_X86_PVCLOCK_H */
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index d88967659098..538738047ff5 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -47,12 +47,6 @@ early_param("no-kvmclock", parse_no_kvmclock);
static struct pvclock_vsyscall_time_info *hv_clock;
static struct pvclock_wall_clock wall_clock;
-struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
-{
- return hv_clock;
-}
-EXPORT_SYMBOL_GPL(pvclock_pvti_cpu0_va);
-
/*
* The wallclock is the time of day when we booted. Since then, some time may
* have elapsed since the hypervisor wrote the data. So we try to account for
@@ -334,6 +328,7 @@ int __init kvm_setup_vsyscall_timeinfo(void)
return 1;
}
+ pvclock_set_pvti_cpu0_va(hv_clock);
put_cpu();
kvm_clock.archdata.vclock_mode = VCLOCK_PVCLOCK;
diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
index 5c3f6d6a5078..cb7d6d9c9c2d 100644
--- a/arch/x86/kernel/pvclock.c
+++ b/arch/x86/kernel/pvclock.c
@@ -25,8 +25,10 @@
#include
#include
+#include
static u8 valid_flags __read_mostly = 0;
+static struct pvclock_vsyscall_time_info *pvti_cpu0_va __read_mostly;
void pvclock_set_flags(u8 flags)
{
@@ -144,3 +146,15 @@ void pvclock_read_wallclock(struct pvclock_wall_clock
*wall_clock,
set_normalized_timespec(ts, now.tv_sec, now.tv_nsec);
}
+
+void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti)
+{
+ WARN_ON(vclock_was_used(VCLOCK_PVCLOCK));
+ pvti_cpu0_va = pvti;
+}
+
+struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
+{
+ return pvti_cpu0_va;
+}
+EXPORT_SYMBOL_GPL(pvclock_pvti_cpu0_va);
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 2/3] x86/xen/time: setup vcpu 0 time info page
In order to support pvclock vdso on xen we need to setup the time
info page for vcpu 0 and register the page with Xen using the
VCPUOP_register_vcpu_time_memory_area hypercall. This hypercall
will also forcefully update the pvti which will set some of the
necessary flags for vdso. Afterwards we check if it supports the
PVCLOCK_TSC_STABLE_BIT flag which is mandatory for having
vdso/vsyscall support. And if so, it will set the cpu 0 pvti that
will be later on used when mapping the vdso image.
The xen headers are also updated to include the new hypercall for
registering the secondary vcpu_time_info struct.
Signed-off-by: Joao Martins
---
Changes since v2:
(Comments from Juergen)
* Omit the blan after the cast on all 3 occurrences.
* Change last VCLOCK_PVCLOCK message to be more descriptive
* Sync the complete vcpu.h header instead of just adding the
needed one. (IOW adding VCPUOP_get_physid)
Changes since v1:
* Check flags ahead to see if the primary clock can use
PVCLOCK_TSC_STABLE_BIT even if secondary registration fails.
(Comments from Boris)
* Remove addr, addr variables;
* Change first pr_debug to pr_warn;
* Change last pr_debug to pr_notice;
* Add routine to solely register secondary time info.
* Move xen_clock to outside xen_setup_vsyscall_time_info to allow
restore path to simply re-register secondary time info. Let us
handle the restore path more gracefully without re-allocating a
page.
* Removed cpu argument from xen_setup_vsyscall_time_info()
* Adjustment failed registration error messages/loglevel to be the same
* Also teardown secondary time info on suspend
Changes since RFC:
(Comments from Boris and David)
* Remove Kconfig option
* Use get_zeroed_page/free/page
* Remove the hypercall availability check
* Unregister pvti with arg.addr.v = NULL if stable bit isn't supported.
(New)
* Set secondary copy on restore such that it works on migration.
* Drop global xen_clock variable and stash it locally on
xen_setup_vsyscall_time_info.
* WARN_ON(ret) if we fail to unregister the pvti.
---
arch/x86/xen/suspend.c | 4 ++
arch/x86/xen/time.c | 100 +++
arch/x86/xen/xen-ops.h | 2 +
include/xen/interface/vcpu.h | 42 ++
4 files changed, 148 insertions(+)
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index d6b1680693a9..800ed36ecfba 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -16,6 +16,8 @@
void xen_arch_pre_suspend(void)
{
+ xen_save_time_memory_area();
+
if (xen_pv_domain())
xen_pv_pre_suspend();
}
@@ -26,6 +28,8 @@ void xen_arch_post_suspend(int cancelled)
xen_pv_post_suspend(cancelled);
else
xen_hvm_post_suspend(cancelled);
+
+ xen_restore_time_memory_area();
}
static void xen_vcpu_notify_restore(void *data)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 1ecb05db3632..3bf72b933825 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -370,6 +370,105 @@ static const struct pv_time_ops xen_time_ops __initconst
= {
.steal_clock = xen_steal_clock,
};
+static struct pvclock_vsyscall_time_info *xen_clock __read_mostly;
+
+void xen_save_time_memory_area(void)
+{
+ struct vcpu_register_time_memory_area t;
+ int ret;
+
+ if (!xen_clock)
+ return;
+
+ t.addr.v = NULL;
+
+ ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t);
+ if (ret != 0)
+ pr_notice("Cannot save secondary vcpu_time_info (err %d)",
+ ret);
+ else
+ clear_page(xen_clock);
+}
+
+void xen_restore_time_memory_area(void)
+{
+ struct vcpu_register_time_memory_area t;
+ int ret;
+
+ if (!xen_clock)
+ return;
+
+ t.addr.v = &xen_clock->pvti;
+
+ ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t);
+
+ /*
+* We don't disable VCLOCK_PVCLOCK entirely if it fails to register the
+* secondary time info with Xen or if we migrated to a host without the
+* necessary flags. On both of these cases what happens is either
+* process seeing a zeroed out pvti or seeing no PVCLOCK_TSC_STABLE_BIT
+* bit set. Userspace checks the latter and if 0, it discards the data
+* in pvti and fallbacks to a system call for a reliable timestamp.
+*/
+ if (ret != 0)
+ pr_notice("Cannot restore secondary vcpu_time_info (err %d)",
+ ret);
+}
+
+static void xen_setup_vsyscall_time_info(void)
+{
+ struct vcpu_register_time_memory_area t;
+ struct pvclock_vsyscall_time_info *ti;
+ struct pvclock_vcpu_time_info *pvti;
+ int ret;
+
+ pvti = &__this_cpu_read(xen_vcpu)->time;
+
+ /*
+* We check ahead on the primary time info if this
+* bit is supported hence speeding up Xen clock
[Xen-devel] [PATCH v3 0/3] x86/xen: pvclock vdso support
Hey, This take 3 for vdso for Xen. PVCLOCK_TSC_STABLE_BIT can be set starting Xen 4.8 which is required for vdso time related calls. In order to have it on, you need to have the hypervisor clocksource be TSC e.g. with the following boot params "clocksource=tsc tsc=stable:socket". Series is structured as following: Patch 1 streamlines pvti page get/set in pvclock for both of its users Patch 2 registers the pvti page on Xen and sets it in pvclock accordingly Patch 3 adds a file to KVM/Xen maintainers for tracking pvclock ABI changes. Changelog is included in individual patches. (only patch 2 changed in this version) Thanks, Joao Joao Martins (3): x86/pvclock: add setter for pvclock_pvti_cpu0_va x86/xen/time: setup vcpu 0 time info page MAINTAINERS: xen, kvm: track pvclock-abi.h changes MAINTAINERS| 2 + arch/x86/include/asm/pvclock.h | 19 arch/x86/kernel/kvmclock.c | 7 +-- arch/x86/kernel/pvclock.c | 14 ++ arch/x86/xen/suspend.c | 4 ++ arch/x86/xen/time.c| 100 + arch/x86/xen/xen-ops.h | 2 + include/xen/interface/vcpu.h | 42 + 8 files changed, 175 insertions(+), 15 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 3/3] MAINTAINERS: xen, kvm: track pvclock-abi.h changes
This file defines an ABI shared between guest and hypervisor(s) (KVM, Xen) and as such there should be an correspondent entry in MAINTAINERS file. Notice that there's already a text notice at the top of the header file, hence this commit simply enforces it more explicitly and have both peers noticed when such changes happen. Signed-off-by: Joao Martins Acked-by: Juergen Gross --- In the end, I choose the originally posted because this is so far the only ABI shared between Xen/KVM. Therefore whenever we have more things shared it would deserve its own place in MAINTAINERS file. If the thinking is wrong, I can switch to the alternative with a "PARAVIRT ABIS" section. Changes since v1: * Add Juergen Gross Acked-by. --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6671f375f7fc..a4834c3c377a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7603,6 +7603,7 @@ S:Supported F: arch/x86/kvm/ F: arch/x86/include/uapi/asm/kvm* F: arch/x86/include/asm/kvm* +F: arch/x86/include/asm/pvclock-abi.h F: arch/x86/kernel/kvm.c F: arch/x86/kernel/kvmclock.c @@ -14718,6 +14719,7 @@ F: arch/x86/xen/ F: drivers/*/xen-*front.c F: drivers/xen/ F: arch/x86/include/asm/xen/ +F: arch/x86/include/asm/pvclock-abi.h F: include/xen/ F: include/uapi/xen/ F: Documentation/ABI/stable/sysfs-hypervisor-xen -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] xen/credit2: add missing unlock
On Wed, 2017-09-27 at 12:46 +0100, Wei Liu wrote:
> Coverity-ID: 1418531
>
> Signed-off-by: Wei Liu
> ---
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index d33c881c3d..18f39cafe4 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -2831,6 +2831,7 @@ csched2_dom_cntl(
> if ( op->u.credit2.cap > 100 * sdom->nr_vcpus )
> {
> rc = -EINVAL;
> +write_unlock_irqrestore(&prv->lock, flags);
>
Indeed... :-/
Reviewed-by: Dario Faggioli
Regards,
Dario
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5] x86/hvm: Implement hvmemul_write() using real mappings
On 27/09/17 12:48, Alexandru Stefan ISAILA wrote: > On Mi, 2017-09-27 at 09:38 +0100, Andrew Cooper wrote: >> On 27/09/2017 09:04, Alexandru Isaila wrote: >>> From: Andrew Cooper >>> >>> >>> -return X86EMUL_EXCEPTION; >>> -case HVMTRANS_bad_gfn_to_mfn: >>> -return hvmemul_linear_mmio_write(addr, bytes, p_data, >>> pfec, hvmemul_ctxt, 0); >> Where has the if ( !mapping ) test gone? The HVMTRANS_bad_gfn_to_mfn >> case needs handling. > There was a comment form Jan in V2. NOTE: "v1 > comment:'Pointless"else".'" That means that the "else " text is pointless, not the clause. (Jan: Please do try to be clearer when stating "pointless else", because it really is ambiguous and this mistake is a valid interpretation of your statement.) The call to hvmemul_linear_mmio_write(addr, bytes, p_data, pfec, hvmemul_ctxt, 0); is important, and needs to stay. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/3] x86/xen/time: setup vcpu 0 time info page
On 27/09/17 14:00, Joao Martins wrote:
> In order to support pvclock vdso on xen we need to setup the time
> info page for vcpu 0 and register the page with Xen using the
> VCPUOP_register_vcpu_time_memory_area hypercall. This hypercall
> will also forcefully update the pvti which will set some of the
> necessary flags for vdso. Afterwards we check if it supports the
> PVCLOCK_TSC_STABLE_BIT flag which is mandatory for having
> vdso/vsyscall support. And if so, it will set the cpu 0 pvti that
> will be later on used when mapping the vdso image.
>
> The xen headers are also updated to include the new hypercall for
> registering the secondary vcpu_time_info struct.
>
> Signed-off-by: Joao Martins
> ---
> Changes since v2:
> (Comments from Juergen)
> * Omit the blan after the cast on all 3 occurrences.
> * Change last VCLOCK_PVCLOCK message to be more descriptive
> * Sync the complete vcpu.h header instead of just adding the
> needed one. (IOW adding VCPUOP_get_physid)
>
> Changes since v1:
> * Check flags ahead to see if the primary clock can use
> PVCLOCK_TSC_STABLE_BIT even if secondary registration fails.
> (Comments from Boris)
> * Remove addr, addr variables;
> * Change first pr_debug to pr_warn;
> * Change last pr_debug to pr_notice;
> * Add routine to solely register secondary time info.
> * Move xen_clock to outside xen_setup_vsyscall_time_info to allow
> restore path to simply re-register secondary time info. Let us
> handle the restore path more gracefully without re-allocating a
> page.
> * Removed cpu argument from xen_setup_vsyscall_time_info()
> * Adjustment failed registration error messages/loglevel to be the same
> * Also teardown secondary time info on suspend
>
> Changes since RFC:
> (Comments from Boris and David)
> * Remove Kconfig option
> * Use get_zeroed_page/free/page
> * Remove the hypercall availability check
> * Unregister pvti with arg.addr.v = NULL if stable bit isn't supported.
> (New)
> * Set secondary copy on restore such that it works on migration.
> * Drop global xen_clock variable and stash it locally on
> xen_setup_vsyscall_time_info.
> * WARN_ON(ret) if we fail to unregister the pvti.
> ---
> arch/x86/xen/suspend.c | 4 ++
> arch/x86/xen/time.c | 100
> +++
> arch/x86/xen/xen-ops.h | 2 +
> include/xen/interface/vcpu.h | 42 ++
> 4 files changed, 148 insertions(+)
>
> diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
> index d6b1680693a9..800ed36ecfba 100644
> --- a/arch/x86/xen/suspend.c
> +++ b/arch/x86/xen/suspend.c
> @@ -16,6 +16,8 @@
>
> void xen_arch_pre_suspend(void)
> {
> + xen_save_time_memory_area();
> +
> if (xen_pv_domain())
> xen_pv_pre_suspend();
> }
> @@ -26,6 +28,8 @@ void xen_arch_post_suspend(int cancelled)
> xen_pv_post_suspend(cancelled);
> else
> xen_hvm_post_suspend(cancelled);
> +
> + xen_restore_time_memory_area();
> }
>
> static void xen_vcpu_notify_restore(void *data)
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index 1ecb05db3632..3bf72b933825 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -370,6 +370,105 @@ static const struct pv_time_ops xen_time_ops
> __initconst = {
> .steal_clock = xen_steal_clock,
> };
>
> +static struct pvclock_vsyscall_time_info *xen_clock __read_mostly;
> +
> +void xen_save_time_memory_area(void)
> +{
> + struct vcpu_register_time_memory_area t;
> + int ret;
> +
> + if (!xen_clock)
> + return;
> +
> + t.addr.v = NULL;
> +
> + ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t);
> + if (ret != 0)
> + pr_notice("Cannot save secondary vcpu_time_info (err %d)",
> + ret);
> + else
> + clear_page(xen_clock);
> +}
> +
> +void xen_restore_time_memory_area(void)
> +{
> + struct vcpu_register_time_memory_area t;
> + int ret;
> +
> + if (!xen_clock)
> + return;
> +
> + t.addr.v = &xen_clock->pvti;
> +
> + ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t);
> +
> + /*
> + * We don't disable VCLOCK_PVCLOCK entirely if it fails to register the
> + * secondary time info with Xen or if we migrated to a host without the
> + * necessary flags. On both of these cases what happens is either
> + * process seeing a zeroed out pvti or seeing no PVCLOCK_TSC_STABLE_BIT
> + * bit set. Userspace checks the latter and if 0, it discards the data
> + * in pvti and fallbacks to a system call for a reliable timestamp.
> + */
> + if (ret != 0)
> + pr_notice("Cannot restore secondary vcpu_time_info (err %d)",
> + ret);
> +}
> +
> +static void xen_setup_vsyscall_time_info(void)
> +{
> + struct vcpu_register_time_memory_area t;
> + struct pvclock_vsyscall_time_info *ti;
> +
Re: [Xen-devel] [PATCH 2/2] python/libxc: extend the call to get/set cap for credit2
On Wed, 2017-09-27 at 12:46 +0100, Wei Liu wrote:
> Commit 68817024 ("xen: credit2: allow to set and get utilization
> cap")
> added a new parameter. Implement it for the python binding as well.
>
> Coverity-ID: 1418532
>
Right. Sorry, I tend to forget about these more often that I would want
to. :-(
I'll try to be more careful.
> Signed-off-by: Wei Liu
> ---
> Cc: George Dunlap
> Cc: Dario Faggioli
> Cc: Marek Marczykowski-Górecki
>
FWIW:
Reviewed-by: Dario Faggioli
Regards,
Dario
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] RT-Xen on ARM
Dear Meng Xu, On 22.08.17 05:02, Meng Xu wrote: Given the set of tasks in each VM, we compute the VCPUs' periods and budgets, using the CARTS tool [1]. Note that each task has a period and a worst-case execution time (wcet). [1] https://rtg.cis.upenn.edu/carts/ In a CARTS tool documentation [1] it is said that: "At the same time, it is also accompanied by a lightweight command‐line option that enables our tool to be integrated with other existing toolchains." But there is no CLI usage description in the document. Could you please provide such a description? My intention is to have a set of generated input xml's, feed them to CARTS and get models ready to be parsed to receive domains configuration for each test case. [1] https://rtg.cis.upenn.edu/carts/docs/userguide.pdf -- *Andrii Anisov* ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] python/libxc: extend the call to get/set cap for credit2
On Wed, Sep 27, 2017 at 12:46:22PM +0100, Wei Liu wrote:
> Commit 68817024 ("xen: credit2: allow to set and get utilization cap")
> added a new parameter. Implement it for the python binding as well.
>
> Coverity-ID: 1418532
>
> Signed-off-by: Wei Liu
Acked-by: Marek Marczykowski-Górecki
> ---
> Cc: George Dunlap
> Cc: Dario Faggioli
> Cc: Marek Marczykowski-Górecki
>
> Compile-test only.
> ---
> tools/python/xen/lowlevel/xc/xc.c | 17 ++---
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/tools/python/xen/lowlevel/xc/xc.c
> b/tools/python/xen/lowlevel/xc/xc.c
> index aa9f8e4d9e..f501764100 100644
> --- a/tools/python/xen/lowlevel/xc/xc.c
> +++ b/tools/python/xen/lowlevel/xc/xc.c
> @@ -1348,16 +1348,19 @@ static PyObject
> *pyxc_sched_credit2_domain_set(XcObject *self,
> {
> uint32_t domid;
> uint16_t weight;
> -static char *kwd_list[] = { "domid", "weight", NULL };
> -static char kwd_type[] = "I|H";
> -struct xen_domctl_sched_credit2 sdom;
> +uint16_t cap;
> +static char *kwd_list[] = { "domid", "weight", "cap", NULL };
> +static char kwd_type[] = "I|HH";
> +struct xen_domctl_sched_credit2 sdom = { };
>
> weight = 0;
> +cap = 0;
> if( !PyArg_ParseTupleAndKeywords(args, kwds, kwd_type, kwd_list,
> - &domid, &weight) )
> + &domid, &weight, &cap) )
> return NULL;
>
> sdom.weight = weight;
> +sdom.cap = cap;
>
> if ( xc_sched_credit2_domain_set(self->xc_handle, domid, &sdom) != 0 )
> return pyxc_error_to_exception(self->xc_handle);
> @@ -1369,7 +1372,7 @@ static PyObject *pyxc_sched_credit2_domain_set(XcObject
> *self,
> static PyObject *pyxc_sched_credit2_domain_get(XcObject *self, PyObject
> *args)
> {
> uint32_t domid;
> -struct xen_domctl_sched_credit2 sdom;
> +struct xen_domctl_sched_credit2 sdom = { };
>
> if( !PyArg_ParseTuple(args, "I", &domid) )
> return NULL;
> @@ -1377,8 +1380,8 @@ static PyObject *pyxc_sched_credit2_domain_get(XcObject
> *self, PyObject *args)
> if ( xc_sched_credit2_domain_get(self->xc_handle, domid, &sdom) != 0 )
> return pyxc_error_to_exception(self->xc_handle);
>
> -return Py_BuildValue("{s:H}",
> - "weight", sdom.weight);
> +return Py_BuildValue("{s:HH}",
> + "weight", "cap", sdom.weight, sdom.cap);
> }
>
> static PyObject *pyxc_domain_setmaxmem(XcObject *self, PyObject *args)
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6] x86/hvm: Implement hvmemul_write() using real mappings
From: Andrew Cooper
An access which crosses a page boundary is performed atomically by x86
hardware, albeit with a severe performance penalty. An important corner case
is when a straddled access hits two pages which differ in whether a
translation exists, or in net access rights.
The use of hvm_copy*() in hvmemul_write() is problematic, because it performs
a translation then completes the partial write, before moving onto the next
translation.
If an individual emulated write straddles two pages, the first of which is
writable, and the second of which is not, the first half of the write will
complete before #PF is raised from the second half.
This results in guest state corruption as a side effect of emulation, which
has been observed to cause windows to crash while under introspection.
Introduce the hvmemul_{,un}map_linear_addr() helpers, which translate an
entire contents of a linear access, and vmap() the underlying frames to
provide a contiguous virtual mapping for the emulator to use. This is the
same mechanism as used by the shadow emulation code.
This will catch any translation issues and abort the emulation before any
modifications occur.
Signed-off-by: Andrew Cooper
Signed-off-by: Alexandru Isaila
Reviewed-by: Paul Durrant
---
Changes since V5:
- Added address size check
- Added a pages local variable that holds the number of pages
- Addded the !mapping check
---
xen/arch/x86/hvm/emulate.c| 189 ++
xen/include/asm-x86/hvm/emulate.h | 7 ++
2 files changed, 180 insertions(+), 16 deletions(-)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index cc874ce..c563052 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -498,6 +498,170 @@ static int hvmemul_do_mmio_addr(paddr_t mmio_gpa,
}
/*
+ * Map the frame(s) covering an individual linear access, for writeable
+ * access. May return NULL for MMIO, or ERR_PTR(~X86EMUL_*) for other errors
+ * including ERR_PTR(~X86EMUL_OKAY) for write-discard mappings.
+ *
+ * In debug builds, map() checks that each slot in hvmemul_ctxt->mfn[] is
+ * clean before use, and poisions unused slots with INVALID_MFN.
+ */
+static void *hvmemul_map_linear_addr(
+unsigned long linear, unsigned int bytes, uint32_t pfec,
+struct hvm_emulate_ctxt *hvmemul_ctxt)
+{
+struct vcpu *curr = current;
+void *err, *mapping;
+
+/* First and final gfns which need mapping. */
+unsigned long frame = linear >> PAGE_SHIFT, first = frame;
+unsigned long final = (linear + bytes - !!bytes) >> PAGE_SHIFT;
+unsigned long pages = final - first + 1;
+
+if ( hvmemul_ctxt->ctxt.addr_size < 64 )
+{
+frame = (uint32_t)frame;
+final = (uint32_t)final;
+pages = (uint32_t)pages;
+}
+
+/*
+ * mfn points to the next free slot. All used slots have a page reference
+ * held on them.
+ */
+mfn_t *mfn = &hvmemul_ctxt->mfn[0];
+
+/*
+ * The caller has no legitimate reason for trying a zero-byte write, but
+ * final is calculate to fail safe in release builds.
+ *
+ * The maximum write size depends on the number of adjacent mfns[] which
+ * can be vmap()'d, accouting for possible misalignment within the region.
+ * The higher level emulation callers are responsible for ensuring that
+ * mfns[] is large enough for the requested write size.
+ */
+if ( bytes == 0 ||
+ pages > ARRAY_SIZE(hvmemul_ctxt->mfn) )
+{
+ASSERT_UNREACHABLE();
+goto unhandleable;
+}
+
+do {
+enum hvm_translation_result res;
+struct page_info *page;
+pagefault_info_t pfinfo;
+p2m_type_t p2mt;
+
+/* Error checking. Confirm that the current slot is clean. */
+ASSERT(mfn_x(*mfn) == 0);
+
+res = hvm_translate_get_page(curr, frame << PAGE_SHIFT, true, pfec,
+ &pfinfo, &page, NULL, &p2mt);
+
+switch ( res )
+{
+case HVMTRANS_okay:
+break;
+
+case HVMTRANS_bad_linear_to_gfn:
+x86_emul_pagefault(pfinfo.ec, pfinfo.linear, &hvmemul_ctxt->ctxt);
+err = ERR_PTR(~X86EMUL_EXCEPTION);
+goto out;
+
+case HVMTRANS_bad_gfn_to_mfn:
+err = NULL;
+goto out;
+
+case HVMTRANS_gfn_paged_out:
+case HVMTRANS_gfn_shared:
+err = ERR_PTR(~X86EMUL_RETRY);
+goto out;
+
+default:
+goto unhandleable;
+}
+
+*mfn++ = _mfn(page_to_mfn(page));
+
+if ( p2m_is_discard_write(p2mt) )
+{
+err = ERR_PTR(~X86EMUL_OKAY);
+goto out;
+}
+
+} while ( ++frame < final );
+
+/* Entire access within a single frame? */
+if ( first == final )
+mapping = map_domain_page(hvmemul_ctxt->mfn[0]);
+/* Multiple frames? Need to vmap(). */
+else if ( (mapping = vmap(
Re: [Xen-devel] [PATCH v5] x86/hvm: Implement hvmemul_write() using real mappings
>>> On 27.09.17 at 14:11, wrote: > On 27/09/17 12:48, Alexandru Stefan ISAILA wrote: >> On Mi, 2017-09-27 at 09:38 +0100, Andrew Cooper wrote: >>> On 27/09/2017 09:04, Alexandru Isaila wrote: From: Andrew Cooper -return X86EMUL_EXCEPTION; -case HVMTRANS_bad_gfn_to_mfn: -return hvmemul_linear_mmio_write(addr, bytes, p_data, pfec, hvmemul_ctxt, 0); >>> Where has the if ( !mapping ) test gone? The HVMTRANS_bad_gfn_to_mfn >>> case needs handling. >> There was a comment form Jan in V2. NOTE: "v1 >> comment:'Pointless"else".'" > > That means that the "else " text is pointless, not the clause. (Jan: > Please do try to be clearer when stating "pointless else", because it > really is ambiguous and this mistake is a valid interpretation of your > statement.) How would one word this in an unambiguous way? And anyway - it should have occurred to Alexandru that deleting not the "else" alone has an unwanted side effect. If this wasn't enough for the ambiguity to be resolved, he should have asked back. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 01/12] x86/mm: allow a privileged PV domain to map guest mfns
>>> On 27.09.17 at 13:18, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 25 September 2017 14:03
>> >>> On 18.09.17 at 17:31, wrote:
>> > -if ( (real_pg_owner == NULL) || (pg_owner == l1e_owner) ||
>> > +if ( (real_pg_owner == NULL) ||
>> > xsm_priv_mapping(XSM_TARGET, pg_owner, real_pg_owner) )
>> > {
>> > gdprintk(XENLOG_WARNING,
>>
>> I'm concerned of the effect of the change on the code paths
>> which you're not really interested in: alloc_l1_table(),
>> ptwr_emulated_update(), and shadow_get_page_from_l1e() all
>> explicitly pass both domains identical, and are now suddenly able
>> to do things they weren't supposed to do. A similar concern
>> applies to __do_update_va_mapping() calling mod_l1_table().
>>
>> I therefore wonder whether the solution to your problem
>> wouldn't rather be MMU_FOREIGN_PT_UPDATE (name subject
>> to improvement suggestions). This at the same time would
>> address my concern regarding the misleading DOMID_SELF
>> passing when really a foreign domain's page is meant.
>
> Looking at this I wonder whether a cleaner solution would be to introduce a
> new domid: DOMID_ANY. This meaning of this would be along the same sort of
> lines as DOMID_XEN or DOMID_IO and would be used in mmu_update to mean 'any
> page over which the caller has privilege'. Does that sound reasonable?
Not really, no. Even if the caller has privilege over multiple domains,
it should still specify which one it means. Otherwise we may end up
with a page transferring ownership behind its back, and it doing
something to one domain which was meant to be done to another.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 01/12] x86/mm: allow a privileged PV domain to map guest mfns
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 27 September 2017 13:47
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: RE: [PATCH v7 01/12] x86/mm: allow a privileged PV domain to map
> guest mfns
>
> >>> On 27.09.17 at 13:18, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 25 September 2017 14:03
> >> >>> On 18.09.17 at 17:31, wrote:
> >> > -if ( (real_pg_owner == NULL) || (pg_owner == l1e_owner) ||
> >> > +if ( (real_pg_owner == NULL) ||
> >> > xsm_priv_mapping(XSM_TARGET, pg_owner, real_pg_owner) )
> >> > {
> >> > gdprintk(XENLOG_WARNING,
> >>
> >> I'm concerned of the effect of the change on the code paths
> >> which you're not really interested in: alloc_l1_table(),
> >> ptwr_emulated_update(), and shadow_get_page_from_l1e() all
> >> explicitly pass both domains identical, and are now suddenly able
> >> to do things they weren't supposed to do. A similar concern
> >> applies to __do_update_va_mapping() calling mod_l1_table().
> >>
> >> I therefore wonder whether the solution to your problem
> >> wouldn't rather be MMU_FOREIGN_PT_UPDATE (name subject
> >> to improvement suggestions). This at the same time would
> >> address my concern regarding the misleading DOMID_SELF
> >> passing when really a foreign domain's page is meant.
> >
> > Looking at this I wonder whether a cleaner solution would be to introduce a
> > new domid: DOMID_ANY. This meaning of this would be along the same
> sort of
> > lines as DOMID_XEN or DOMID_IO and would be used in mmu_update to
> mean 'any
> > page over which the caller has privilege'. Does that sound reasonable?
>
> Not really, no. Even if the caller has privilege over multiple domains,
> it should still specify which one it means. Otherwise we may end up
> with a page transferring ownership behind its back, and it doing
> something to one domain which was meant to be done to another.
>
Ok, I'll claim the final cmd value then.
Paul
> Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 02/12] x86/mm: add HYPERVISOR_memory_op to acquire guest resources
>>> On 27.09.17 at 13:34, wrote: > On 26/09/17 13:49, Paul Durrant wrote: >>> -Original Message- >>> From: Jan Beulich [mailto:jbeul...@suse.com] >>> Sent: 26 September 2017 13:35 >>> To: Andrew Cooper ; Paul Durrant >>> >>> Cc: xen-de...@lists.xenproject.org >>> Subject: RE: [PATCH v7 02/12] x86/mm: add HYPERVISOR_memory_op to >>> acquire guest resources >>> >> On 26.09.17 at 14:20, wrote: > -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > Paul Durrant > Sent: 25 September 2017 16:00 > To: 'Jan Beulich' > Cc: Andrew Cooper ; xen- > de...@lists.xenproject.org > Subject: Re: [Xen-devel] [PATCH v7 02/12] x86/mm: add > HYPERVISOR_memory_op to acquire guest resources > >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 25 September 2017 15:23 >> To: Paul Durrant >> Cc: Andrew Cooper ; xen- >> de...@lists.xenproject.org >> Subject: Re: [PATCH v7 02/12] x86/mm: add HYPERVISOR_memory_op >>> to >> acquire guest resources >> > On 18.09.17 at 17:31, wrote: >>> Certain memory resources associated with a guest are not necessarily >>> present in the guest P2M and so are not necessarily available to be >>> foreign-mapped by a tools domain unless they are inserted, which >>> risks >>> shattering a super-page mapping. >> Btw., I'm additionally having trouble seeing this shattering of a >> superpage: For one, xc_core_arch_get_scratch_gpfn() could be >> a little less simplistic. And then even with the currently chosen >> value (outside of the range of valid GFNs at that point in time) >> there shouldn't be a larger page to be shattered, as there should >> be no mapping at all at that index. But perhaps I'm just blind and >> don't see the obvious ... > The shattering was Andrew's observation. Andrew, can you comment? > Andrew commented verbally on this. It's not actually a shattering as such... The issue, apparently, is that adding the 4k grant table frame into the guest p2m will potentially cause creation of all layers of page table but removing it again will only remove the L1 entry. Thus it is no longer possible to use a superpage for that mapping at any point subsequently. >>> First of all - what would cause a mapping to appear at that slot (or in >>> a range covering that slot). > > ??? > > At the moment, the toolstack's *only* way of editing the grant table of > an HVM guest is to add it into the p2m, map the gfn, write two values, > and unmap it. That is how a 4k mapping gets added, which forces an > allocation or shattering to cause a L1 table to exist. > > This is a kludge and is architecturally unclean. Well, if the grant table related parts of series here was presented to be simply cleaning up a kludge, I'd probably be fine. But so far it has been claimed that there are other bad effects, besides this just being (as I would call it) sub-optimal. >>> And then, while re-combining contiguous >>> mappings indeed doesn't exist right now, replacing a non-leaf entry >>> (page table) with a large page is very well supported (see e.g. >>> ept_set_entry(), which even has a comment to that effect). > > I don't see anything equivalent in the NPT or IOMMU logic. Look for intermediate_entry in p2m_pt_set_entry(). In AMD IOMMU code see iommu_merge_pages(). For VT-d I agree. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 113850: regressions - FAIL
flight 113850 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/113850/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt broken in 113840 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 113387 build-armhf-libvirt 5 host-build-prep fail in 113840 REGR. vs. 113387 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 113840 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 1 build-check(1) blocked in 113840 n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked in 113840 n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked in 113840 n/a test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 113387 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail blocked in 113387 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 113840 blocked in 113387 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 113387 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 113387 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 113387 test-amd64-amd64-xl-rtds 10 debian-install fail like 113387 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 113387 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass version targeted for testing: xen a8ea6e2688118a3e19e29b39e316faa5f96ab9d1 baseline version: xen 16b1414de91b5a82a0996c67f6db3af7d7e32873 Last test of basis 113387 2017-09-12 23:20:09 Z 14 days Failing since113430 2017-09-14 01:24:48 Z 13 days 29 attempts Testing same since 113840 2017-09-26 20:49:20 Z0 days2 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Anthony PERARD Bhupinder Thakur Bori
Re: [Xen-devel] [PATCH v7 01/12] x86/mm: allow a privileged PV domain to map guest mfns
>>> On 27.09.17 at 14:49, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 27 September 2017 13:47
>> To: Paul Durrant
>> Cc: Andrew Cooper ; xen-
>> de...@lists.xenproject.org
>> Subject: RE: [PATCH v7 01/12] x86/mm: allow a privileged PV domain to map
>> guest mfns
>>
>> >>> On 27.09.17 at 13:18, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: 25 September 2017 14:03
>> >> >>> On 18.09.17 at 17:31, wrote:
>> >> > -if ( (real_pg_owner == NULL) || (pg_owner == l1e_owner) ||
>> >> > +if ( (real_pg_owner == NULL) ||
>> >> > xsm_priv_mapping(XSM_TARGET, pg_owner, real_pg_owner) )
>> >> > {
>> >> > gdprintk(XENLOG_WARNING,
>> >>
>> >> I'm concerned of the effect of the change on the code paths
>> >> which you're not really interested in: alloc_l1_table(),
>> >> ptwr_emulated_update(), and shadow_get_page_from_l1e() all
>> >> explicitly pass both domains identical, and are now suddenly able
>> >> to do things they weren't supposed to do. A similar concern
>> >> applies to __do_update_va_mapping() calling mod_l1_table().
>> >>
>> >> I therefore wonder whether the solution to your problem
>> >> wouldn't rather be MMU_FOREIGN_PT_UPDATE (name subject
>> >> to improvement suggestions). This at the same time would
>> >> address my concern regarding the misleading DOMID_SELF
>> >> passing when really a foreign domain's page is meant.
>> >
>> > Looking at this I wonder whether a cleaner solution would be to introduce a
>> > new domid: DOMID_ANY. This meaning of this would be along the same
>> sort of
>> > lines as DOMID_XEN or DOMID_IO and would be used in mmu_update to
>> mean 'any
>> > page over which the caller has privilege'. Does that sound reasonable?
>>
>> Not really, no. Even if the caller has privilege over multiple domains,
>> it should still specify which one it means. Otherwise we may end up
>> with a page transferring ownership behind its back, and it doing
>> something to one domain which was meant to be done to another.
>>
>
> Ok, I'll claim the final cmd value then.
Final? We've got 5 left (for a total of 3 bits) afaict.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6] x86/hvm: Implement hvmemul_write() using real mappings
>>> On 27.09.17 at 14:39, wrote:
> From: Andrew Cooper
>
> An access which crosses a page boundary is performed atomically by x86
> hardware, albeit with a severe performance penalty. An important corner
> case
> is when a straddled access hits two pages which differ in whether a
> translation exists, or in net access rights.
>
> The use of hvm_copy*() in hvmemul_write() is problematic, because it
> performs
> a translation then completes the partial write, before moving onto the next
> translation.
>
> If an individual emulated write straddles two pages, the first of which is
> writable, and the second of which is not, the first half of the write will
> complete before #PF is raised from the second half.
>
> This results in guest state corruption as a side effect of emulation, which
> has been observed to cause windows to crash while under introspection.
>
> Introduce the hvmemul_{,un}map_linear_addr() helpers, which translate an
> entire contents of a linear access, and vmap() the underlying frames to
> provide a contiguous virtual mapping for the emulator to use. This is the
> same mechanism as used by the shadow emulation code.
>
> This will catch any translation issues and abort the emulation before any
> modifications occur.
>
> Signed-off-by: Andrew Cooper
> Signed-off-by: Alexandru Isaila
> Reviewed-by: Paul Durrant
This very clearly needs dropping with ...
> Changes since V5:
> - Added address size check
> - Added a pages local variable that holds the number of pages
> - Addded the !mapping check
... these.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] Call xen_cleanhighmap() with 4MB aligned for page tables mapping
On 09/27/2017 05:43 AM, Juergen Gross wrote: > On 27/09/17 11:41, Zhenzhong Duan wrote: >> When bootup a PVM guest with large memory(Ex.240GB), XEN provided initial >> mapping overlaps with kernel module virtual space. When mapping in this space >> is cleared by xen_cleanhighmap(), in certain case there could be an 2MB >> mapping >> left. This is due to XEN initialize 4MB aligned mapping but >> xen_cleanhighmap() >> finish at 2MB boundary. Does this mapping need to be 4MB-aligned? (I also think this should go to stable trees) -boris >> >> When module loading is just on top of the 2MB space, got below warning: >> >> WARNING: at mm/vmalloc.c:106 vmap_pte_range+0x14e/0x190() >> Call Trace: >> [] warn_alloc_failed+0xf3/0x160 >> [] __vmalloc_area_node+0x182/0x1c0 >> [] ? module_alloc_update_bounds+0x1e/0x80 >> [] __vmalloc_node_range+0xa7/0x110 >> [] ? module_alloc_update_bounds+0x1e/0x80 >> [] module_alloc+0x64/0x70 >> [] ? module_alloc_update_bounds+0x1e/0x80 >> [] module_alloc_update_bounds+0x1e/0x80 >> [] move_module+0x27/0x150 >> [] layout_and_allocate+0x120/0x1b0 >> [] load_module+0x78/0x640 >> [] ? security_file_permission+0x8b/0x90 >> [] sys_init_module+0x62/0x1e0 >> [] system_call_fastpath+0x16/0x1b >> >> Then the mapping of 2MB is cleared, finally oops when the page in that space >> is >> accessed. >> >> BUG: unable to handle kernel paging request at 88002260 >> IP: [] clear_page_c_e+0x7/0x10 >> PGD 1788067 PUD 178c067 PMD 22434067 PTE 0 >> Oops: 0002 [#1] SMP >> Call Trace: >> [] ? prep_new_page+0x127/0x1c0 >> [] get_page_from_freelist+0x1e2/0x550 >> [] ? ii_iovec_copy_to_user+0x90/0x140 >> [] __alloc_pages_nodemask+0x12d/0x230 >> [] alloc_pages_vma+0xc6/0x1a0 >> [] ? pte_mfn_to_pfn+0x7d/0x100 >> [] do_anonymous_page+0x16b/0x350 >> [] handle_pte_fault+0x1e4/0x200 >> [] ? xen_pmd_val+0xe/0x10 >> [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e >> [] handle_mm_fault+0x15b/0x270 >> [] do_page_fault+0x140/0x470 >> [] page_fault+0x25/0x30 >> >> Call xen_cleanhighmap() with 4MB aligned for page tables mapping to fix it. >> The unnecessory call of xen_cleanhighmap() in DEBUG mode is also removed. >> >> -v2: add comment about XEN alignment from Juergen. >> >> References: >> https://lists.xen.org/archives/html/xen-devel/2012-07/msg01562.html >> Signed-off-by: Zhenzhong Duan > Reviewed-by: Juergen Gross > > > Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] xen: timers: don't miss a timer event because of stop_timer()
On Wed, 2017-09-27 at 04:30 -0600, Jan Beulich wrote: > > > > On 27.09.17 at 12:18, wrote: > > > And that is because the following happens: > > - the CPU wants to go idle > > - sched_tick_suspend() > > rcu_idle_timer_start() > > set_timer(RCU_idle_timer) > > - the CPU goes idle > > ... ... ... > > - RCU_idle_timer's IRQ arrives > > - the CPU wakes up > > - raise_softirq(TIMER_SOFTIRQ) > > - sched_tick_resume() > > rcu_idle_timer_stop() > > stop_timer(RCU_idle_timer) > > deactivate_timer(RCU_idle_timer) > > remove_entry(RCU_idle_timer) // timer out of heap/list > > - do_softirq() (we are inside idle_loop()) > > - softirq_handlers[TIMER_SOFTIRQ]() > > - timer_softirq_action() > > // but the timer is not in the heap/list! > > But this is an extremely special case, not something likely to > happen anywhere else. Hence I wonder whether it wouldn't > be better to handle the special case in a special way, rather > than making generic code fit the special case. > Well, yes. As said, this "new" timer is the first, and for now the only, that follow this pattern. And I also agree that this is not something we must expect to see to happen much more (if at all). Still, I continue to think that with a timer already expired, its IRQ already delivered and handled and the relative TIMER_SOFTIRQ already risen, we should arrange for the timer handler to run, in the general case. > Or wait - > wouldn't all you need be to avoid calling stop_timer() in the > call tree above, if the timer's expiry has passed (suitably > explained in a comment)? > Yes. For the reason stated above, I addressed the problem at the generic code level. If that doesn't fly, I'll do like this. I had thought about that, and although I haven't tried, I think it works for this case. Thanks and Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 3/3] MAINTAINERS: xen, kvm: track pvclock-abi.h changes
This file defines an ABI shared between guest and hypervisor(s) (KVM, Xen) and as such there should be an correspondent entry in MAINTAINERS file. Notice that there's already a text notice at the top of the header file, hence this commit simply enforces it more explicitly and have both peers noticed when such changes happen. Signed-off-by: Joao Martins Acked-by: Juergen Gross --- In the end, I choose the originally posted because this is so far the only ABI shared between Xen/KVM. Therefore whenever we have more things shared it would deserve its own place in MAINTAINERS file. If the thinking is wrong, I can switch to the alternative with a "PARAVIRT ABIS" section. Changes since v1: * Add Juergen Gross Acked-by. --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6671f375f7fc..a4834c3c377a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7603,6 +7603,7 @@ S:Supported F: arch/x86/kvm/ F: arch/x86/include/uapi/asm/kvm* F: arch/x86/include/asm/kvm* +F: arch/x86/include/asm/pvclock-abi.h F: arch/x86/kernel/kvm.c F: arch/x86/kernel/kvmclock.c @@ -14718,6 +14719,7 @@ F: arch/x86/xen/ F: drivers/*/xen-*front.c F: drivers/xen/ F: arch/x86/include/asm/xen/ +F: arch/x86/include/asm/pvclock-abi.h F: include/xen/ F: include/uapi/xen/ F: Documentation/ABI/stable/sysfs-hypervisor-xen -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 0/3] x86/xen: pvclock vdso support
Hey, This is take 4 for vdso for Xen. PVCLOCK_TSC_STABLE_BIT can be set starting Xen 4.8 which is required for vdso time related calls. In order to have it on, you need to have the hypervisor clocksource be TSC e.g. with the following boot params "clocksource=tsc tsc=stable:socket". Series is structured as following: Patch 1 streamlines pvti page get/set in pvclock for both of its users Patch 2 registers the pvti page on Xen and sets it in pvclock accordingly Patch 3 adds a file to KVM/Xen maintainers for tracking pvclock ABI changes. Changelog is included in individual patches. (only patch 2 changed in this version) Thanks, Joao Joao Martins (3): x86/pvclock: add setter for pvclock_pvti_cpu0_va x86/xen/time: setup vcpu 0 time info page MAINTAINERS: xen, kvm: track pvclock-abi.h changes MAINTAINERS| 2 + arch/x86/include/asm/pvclock.h | 19 arch/x86/kernel/kvmclock.c | 7 +-- arch/x86/kernel/pvclock.c | 14 ++ arch/x86/xen/suspend.c | 4 ++ arch/x86/xen/time.c| 100 + arch/x86/xen/xen-ops.h | 2 + include/xen/interface/vcpu.h | 42 + 8 files changed, 175 insertions(+), 15 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 1/3] x86/pvclock: add setter for pvclock_pvti_cpu0_va
Right now there is only a pvclock_pvti_cpu0_va() which is defined
on kvmclock since:
commit dac16fba6fc5
("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap")
The only user of this interface so far is kvm. This commit adds a
setter function for the pvti page and moves pvclock_pvti_cpu0_va
to pvclock, which is a more generic place to have it; and would
allow other PV clocksources to use it, such as Xen.
Signed-off-by: Joao Martins
Acked-by: Andy Lutomirski
---
Changes since v1:
* Rebased: the only conflict was that I had move the export
pvclock_pvti_cpu0_va() symbol as it is used by kvm PTP driver.
* Do not initialize pvti_cpu0_va to NULL (checkpatch error)
( Comments from Andy Lutomirski )
* Removed asm/pvclock.h 'pvclock_set_pvti_cpu0_va' definition
for non !PARAVIRT_CLOCK to better track screwed Kconfig stuff.
* Add his Acked-by (provided the previous adjustment was made)
Changes since RFC:
(Comments from Andy Lutomirski)
* Add __init to pvclock_set_pvti_cpu0_va
* Add WARN_ON(vclock_was_used(VCLOCK_PVCLOCK)) to
pvclock_set_pvti_cpu0_va
---
arch/x86/include/asm/pvclock.h | 19 ++-
arch/x86/kernel/kvmclock.c | 7 +--
arch/x86/kernel/pvclock.c | 14 ++
3 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
index 448cfe1b48cf..6f228f90cdd7 100644
--- a/arch/x86/include/asm/pvclock.h
+++ b/arch/x86/include/asm/pvclock.h
@@ -4,15 +4,6 @@
#include
#include
-#ifdef CONFIG_KVM_GUEST
-extern struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void);
-#else
-static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
-{
- return NULL;
-}
-#endif
-
/* some helper functions for xen and kvm pv clock sources */
u64 pvclock_clocksource_read(struct pvclock_vcpu_time_info *src);
u8 pvclock_read_flags(struct pvclock_vcpu_time_info *src);
@@ -101,4 +92,14 @@ struct pvclock_vsyscall_time_info {
#define PVTI_SIZE sizeof(struct pvclock_vsyscall_time_info)
+#ifdef CONFIG_PARAVIRT_CLOCK
+void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti);
+struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void);
+#else
+static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
+{
+ return NULL;
+}
+#endif
+
#endif /* _ASM_X86_PVCLOCK_H */
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index d88967659098..538738047ff5 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -47,12 +47,6 @@ early_param("no-kvmclock", parse_no_kvmclock);
static struct pvclock_vsyscall_time_info *hv_clock;
static struct pvclock_wall_clock wall_clock;
-struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
-{
- return hv_clock;
-}
-EXPORT_SYMBOL_GPL(pvclock_pvti_cpu0_va);
-
/*
* The wallclock is the time of day when we booted. Since then, some time may
* have elapsed since the hypervisor wrote the data. So we try to account for
@@ -334,6 +328,7 @@ int __init kvm_setup_vsyscall_timeinfo(void)
return 1;
}
+ pvclock_set_pvti_cpu0_va(hv_clock);
put_cpu();
kvm_clock.archdata.vclock_mode = VCLOCK_PVCLOCK;
diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
index 5c3f6d6a5078..cb7d6d9c9c2d 100644
--- a/arch/x86/kernel/pvclock.c
+++ b/arch/x86/kernel/pvclock.c
@@ -25,8 +25,10 @@
#include
#include
+#include
static u8 valid_flags __read_mostly = 0;
+static struct pvclock_vsyscall_time_info *pvti_cpu0_va __read_mostly;
void pvclock_set_flags(u8 flags)
{
@@ -144,3 +146,15 @@ void pvclock_read_wallclock(struct pvclock_wall_clock
*wall_clock,
set_normalized_timespec(ts, now.tv_sec, now.tv_nsec);
}
+
+void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti)
+{
+ WARN_ON(vclock_was_used(VCLOCK_PVCLOCK));
+ pvti_cpu0_va = pvti;
+}
+
+struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
+{
+ return pvti_cpu0_va;
+}
+EXPORT_SYMBOL_GPL(pvclock_pvti_cpu0_va);
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 2/3] x86/xen/time: setup vcpu 0 time info page
In order to support pvclock vdso on xen we need to setup the time
info page for vcpu 0 and register the page with Xen using the
VCPUOP_register_vcpu_time_memory_area hypercall. This hypercall
will also forcefully update the pvti which will set some of the
necessary flags for vdso. Afterwards we check if it supports the
PVCLOCK_TSC_STABLE_BIT flag which is mandatory for having
vdso/vsyscall support. And if so, it will set the cpu 0 pvti that
will be later on used when mapping the vdso image.
The xen headers are also updated to include the new hypercall for
registering the secondary vcpu_time_info struct.
Signed-off-by: Joao Martins
---
Changes since v3:
(Comments from Juergen)
* Remove _t added suffix from *GUEST_HANDLE* when sync vcpu.h
with the latest
Changes since v2:
(Comments from Juergen)
* Omit the blank after the cast on all 3 occurrences.
* Change last VCLOCK_PVCLOCK message to be more descriptive
* Sync the complete vcpu.h header instead of just adding the
needed one. (IOW adding VCPUOP_get_physid)
Changes since v1:
* Check flags ahead to see if the primary clock can use
PVCLOCK_TSC_STABLE_BIT even if secondary registration fails.
(Comments from Boris)
* Remove addr, addr variables;
* Change first pr_debug to pr_warn;
* Change last pr_debug to pr_notice;
* Add routine to solely register secondary time info.
* Move xen_clock to outside xen_setup_vsyscall_time_info to allow
restore path to simply re-register secondary time info. Let us
handle the restore path more gracefully without re-allocating a
page.
* Removed cpu argument from xen_setup_vsyscall_time_info()
* Adjustment failed registration error messages/loglevel to be the same
* Also teardown secondary time info on suspend
Changes since RFC:
(Comments from Boris and David)
* Remove Kconfig option
* Use get_zeroed_page/free/page
* Remove the hypercall availability check
* Unregister pvti with arg.addr.v = NULL if stable bit isn't supported.
(New)
* Set secondary copy on restore such that it works on migration.
* Drop global xen_clock variable and stash it locally on
xen_setup_vsyscall_time_info.
* WARN_ON(ret) if we fail to unregister the pvti.
---
arch/x86/xen/suspend.c | 4 ++
arch/x86/xen/time.c | 100 +++
arch/x86/xen/xen-ops.h | 2 +
include/xen/interface/vcpu.h | 42 ++
4 files changed, 148 insertions(+)
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index d6b1680693a9..800ed36ecfba 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -16,6 +16,8 @@
void xen_arch_pre_suspend(void)
{
+ xen_save_time_memory_area();
+
if (xen_pv_domain())
xen_pv_pre_suspend();
}
@@ -26,6 +28,8 @@ void xen_arch_post_suspend(int cancelled)
xen_pv_post_suspend(cancelled);
else
xen_hvm_post_suspend(cancelled);
+
+ xen_restore_time_memory_area();
}
static void xen_vcpu_notify_restore(void *data)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 1ecb05db3632..3bf72b933825 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -370,6 +370,105 @@ static const struct pv_time_ops xen_time_ops __initconst
= {
.steal_clock = xen_steal_clock,
};
+static struct pvclock_vsyscall_time_info *xen_clock __read_mostly;
+
+void xen_save_time_memory_area(void)
+{
+ struct vcpu_register_time_memory_area t;
+ int ret;
+
+ if (!xen_clock)
+ return;
+
+ t.addr.v = NULL;
+
+ ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t);
+ if (ret != 0)
+ pr_notice("Cannot save secondary vcpu_time_info (err %d)",
+ ret);
+ else
+ clear_page(xen_clock);
+}
+
+void xen_restore_time_memory_area(void)
+{
+ struct vcpu_register_time_memory_area t;
+ int ret;
+
+ if (!xen_clock)
+ return;
+
+ t.addr.v = &xen_clock->pvti;
+
+ ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t);
+
+ /*
+* We don't disable VCLOCK_PVCLOCK entirely if it fails to register the
+* secondary time info with Xen or if we migrated to a host without the
+* necessary flags. On both of these cases what happens is either
+* process seeing a zeroed out pvti or seeing no PVCLOCK_TSC_STABLE_BIT
+* bit set. Userspace checks the latter and if 0, it discards the data
+* in pvti and fallbacks to a system call for a reliable timestamp.
+*/
+ if (ret != 0)
+ pr_notice("Cannot restore secondary vcpu_time_info (err %d)",
+ ret);
+}
+
+static void xen_setup_vsyscall_time_info(void)
+{
+ struct vcpu_register_time_memory_area t;
+ struct pvclock_vsyscall_time_info *ti;
+ struct pvclock_vcpu_time_info *pvti;
+ int ret;
+
+ pvti = &__this_cpu_read(xen_vcpu)->time;
+
Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md
On Wed, 2017-09-27 at 08:57 -0400, Robert VanVossen wrote: > On 9/26/2017 3:12 AM, Dario Faggioli wrote: > > [Cc-list modified by removing someone and adding someone else] > > > > Actually, the best candidate for gaining security support, is IMO > > ARINC. Code is also rather simple and "stable" (hasn't changed in > > the > > last... years!) and it's used by DornerWorks' people for some of > > their > > projects (I think?). It's also not tested in OSSTest, though, and > > considering how special purpose it is, I think we're not totally > > comfortable marking it as Sec-Supported, without feedback from the > > maintainers. > > > > George, Josh, Robert? > > > > Yes, we do still use the ARINC653 scheduler. Since it is so simple, > it hasn't > really needed any modifications in the last couple years. > Hehe :-) > We are not really sure what kind of feedback you are looking from us > in regards > to marking it sec-supported, but would be happy to try and answer any > questions. > If you have any specific questions or requests, we can discuss it > internally and > get back to you. > Right. So, that's something we are still in the process of defining properly. To have an idea, you may have a look at George's email, in this thread (you weren't Cc-ed yet): https://www.mail-archive.com/xen-devel@lists.xen.org/msg123768.html And also to this other ones: https://www.mail-archive.com/xen-devel@lists.xen.org/msg84376.html https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg00171.h tml Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6] x86/hvm: Implement hvmemul_write() using real mappings
>>> On 27.09.17 at 14:39, wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -498,6 +498,170 @@ static int hvmemul_do_mmio_addr(paddr_t mmio_gpa,
> }
>
> /*
> + * Map the frame(s) covering an individual linear access, for writeable
> + * access. May return NULL for MMIO, or ERR_PTR(~X86EMUL_*) for other errors
> + * including ERR_PTR(~X86EMUL_OKAY) for write-discard mappings.
> + *
> + * In debug builds, map() checks that each slot in hvmemul_ctxt->mfn[] is
> + * clean before use, and poisions unused slots with INVALID_MFN.
> + */
> +static void *hvmemul_map_linear_addr(
> +unsigned long linear, unsigned int bytes, uint32_t pfec,
> +struct hvm_emulate_ctxt *hvmemul_ctxt)
> +{
> +struct vcpu *curr = current;
> +void *err, *mapping;
> +
> +/* First and final gfns which need mapping. */
> +unsigned long frame = linear >> PAGE_SHIFT, first = frame;
> +unsigned long final = (linear + bytes - !!bytes) >> PAGE_SHIFT;
> +unsigned long pages = final - first + 1;
This is right for the 64-bit wrapping case afaics.
> +if ( hvmemul_ctxt->ctxt.addr_size < 64 )
> +{
> +frame = (uint32_t)frame;
> +final = (uint32_t)final;
> +pages = (uint32_t)pages;
> +}
And this isn't right either, as here and above 12 bits of the linear
address were shifted out already.
> +/*
> + * mfn points to the next free slot. All used slots have a page
> reference
> + * held on them.
> + */
> +mfn_t *mfn = &hvmemul_ctxt->mfn[0];
In C89 declarations can't follow statements.
> +/*
> + * The caller has no legitimate reason for trying a zero-byte write, but
> + * final is calculate to fail safe in release builds.
> + *
> + * The maximum write size depends on the number of adjacent mfns[] which
> + * can be vmap()'d, accouting for possible misalignment within the
> region.
> + * The higher level emulation callers are responsible for ensuring that
> + * mfns[] is large enough for the requested write size.
> + */
> +if ( bytes == 0 ||
> + pages > ARRAY_SIZE(hvmemul_ctxt->mfn) )
> +{
> +ASSERT_UNREACHABLE();
> +goto unhandleable;
> +}
> +
> +do {
> +enum hvm_translation_result res;
> +struct page_info *page;
> +pagefault_info_t pfinfo;
> +p2m_type_t p2mt;
> +
> +/* Error checking. Confirm that the current slot is clean. */
> +ASSERT(mfn_x(*mfn) == 0);
> +
> +res = hvm_translate_get_page(curr, frame << PAGE_SHIFT, true, pfec,
> + &pfinfo, &page, NULL, &p2mt);
> +
> +switch ( res )
> +{
> +case HVMTRANS_okay:
> +break;
> +
> +case HVMTRANS_bad_linear_to_gfn:
> +x86_emul_pagefault(pfinfo.ec, pfinfo.linear,
> &hvmemul_ctxt->ctxt);
> +err = ERR_PTR(~X86EMUL_EXCEPTION);
> +goto out;
> +
> +case HVMTRANS_bad_gfn_to_mfn:
> +err = NULL;
> +goto out;
> +
> +case HVMTRANS_gfn_paged_out:
> +case HVMTRANS_gfn_shared:
> +err = ERR_PTR(~X86EMUL_RETRY);
> +goto out;
> +
> +default:
> +goto unhandleable;
> +}
> +
> +*mfn++ = _mfn(page_to_mfn(page));
> +
> +if ( p2m_is_discard_write(p2mt) )
> +{
> +err = ERR_PTR(~X86EMUL_OKAY);
> +goto out;
> +}
> +
> +} while ( ++frame < final );
With wrapping in mind, as Andrew did say on v5, this can't be <
anymore. Also see the additional explanation I gave for what
this needs to become. Same for hvmemul_unmap_linear_addr()
then (to state the obvious).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] RT-Xen on ARM
Hi Andrii, On Wed, Sep 27, 2017 at 8:37 AM, Andrii Anisov wrote: > > Dear Meng Xu, > > > On 22.08.17 05:02, Meng Xu wrote: >> >> Given the set of tasks in each VM, we compute the VCPUs' periods and >> budgets, using the CARTS tool [1]. Note that each task has a period >> and a worst-case execution time (wcet). >> >> [1] https://rtg.cis.upenn.edu/carts/ > > > In a CARTS tool documentation [1] it is said that: > "At the same time, it is also accompanied by a lightweight command‐line > option that enables our tool to be integrated with other existing > toolchains." > > But there is no CLI usage description in the document. Could you please > provide such a description? The command is: java -jar carts.jar inputfile outputfile An example command is: java -jar carts.jar 1-1.10-in.xml MPR2 1-1.10-out.xml Best, Meng -- Meng Xu Ph.D. Candidate in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/3] x86/xen/time: setup vcpu 0 time info page
On 09/27/2017 01:14 PM, Juergen Gross wrote:
> On 27/09/17 14:00, Joao Martins wrote:
[...]
>> diff --git a/include/xen/interface/vcpu.h b/include/xen/interface/vcpu.h
>> index 98188c87f5c1..b4a1eabcf1c4 100644
>> --- a/include/xen/interface/vcpu.h
>> +++ b/include/xen/interface/vcpu.h
>> @@ -178,4 +178,46 @@ DEFINE_GUEST_HANDLE_STRUCT(vcpu_register_vcpu_info);
>>
>> /* Send an NMI to the specified VCPU. @extra_arg == NULL. */
>> #define VCPUOP_send_nmi 11
>> +
>> +/*
>> + * Get the physical ID information for a pinned vcpu's underlying physical
>> + * processor. The physical ID informmation is architecture-specific.
>> + * On x86: id[31:0]=apic_id, id[63:32]=acpi_id.
>> + * This command returns -EINVAL if it is not a valid operation for this
>> VCPU.
>> + */
>> +#define VCPUOP_get_physid 12 /* arg == vcpu_get_physid_t */
>> +struct vcpu_get_physid {
>> +uint64_t phys_id;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(vcpu_get_physid_t);
>
> DEFINE_GUEST_HANDLE_STRUCT(vcpu_get_physid);
>
>> +#define xen_vcpu_physid_to_x86_apicid(physid) ((uint32_t)(physid))
>> +#define xen_vcpu_physid_to_x86_acpiid(physid) ((uint32_t)((physid) >> 32))
>> +
>> +/*
>> + * Register a memory location to get a secondary copy of the vcpu time
>> + * parameters. The master copy still exists as part of the vcpu shared
>> + * memory area, and this secondary copy is updated whenever the master copy
>> + * is updated (and using the same versioning scheme for synchronisation).
>> + *
>> + * The intent is that this copy may be mapped (RO) into userspace so
>> + * that usermode can compute system time using the time info and the
>> + * tsc. Usermode will see an array of vcpu_time_info structures, one
>> + * for each vcpu, and choose the right one by an existing mechanism
>> + * which allows it to get the current vcpu number (such as via a
>> + * segment limit). It can then apply the normal algorithm to compute
>> + * system time from the tsc.
>> + *
>> + * @extra_arg == pointer to vcpu_register_time_info_memory_area structure.
>> + */
>> +#define VCPUOP_register_vcpu_time_memory_area 13
>> +DEFINE_GUEST_HANDLE_STRUCT(vcpu_time_info_t);
>
> DEFINE_GUEST_HANDLE_STRUCT(vcpu_time_info);
>
>> +struct vcpu_register_time_memory_area {
>> +union {
>> +GUEST_HANDLE(vcpu_time_info_t) h;
>
> GUEST_HANDLE(vcpu_time_info) h;
>
>> +struct pvclock_vcpu_time_info *v;
>> +uint64_t p;
>> +} addr;
>> +};
>> +DEFINE_GUEST_HANDLE_STRUCT(vcpu_register_time_memory_area_t);
>
> DEFINE_GUEST_HANDLE_STRUCT(vcpu_register_time_memory_area);
Oh sorry - I forgot to remove the suffix. In the meantime I sent over v4
addressing the above.
Joao
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86emul: properly refuse LOCK on most 0FC7 insns
On 22/09/17 10:02, Jan Beulich wrote: > When adding support for RDRAND/RDSEED/RDPID I didn't remember to also > update this special early check. Make it (hopefully) future-proof by > also refusing VEX-encodings. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] ts-kernel-build: enable ntfs and fuse support
Wei Liu writes ("[OSSTEST PATCH] ts-kernel-build: enable ntfs and fuse
support"):
> They will be useful for extracting files from Windows and other OSes
> from Dom0 while debugging.
Thanks, pushed to pretest.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/pvh: fix PVHv2 Dom0 memory calculation
PVHv2 is always going to require the usage of memory in order to store
the p2m page tables, either when using hap or shadow.
Fix the condition so memory is reserved unconditionally when trying to
build a PVHv2 Dom0.
Reported-by: Boris Ostrovsky
Signed-off-by: Roger Pau Monné
---
Cc: Boris Ostrovsky
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/dom0_build.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index f616b99ddc..424192a7c4 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -263,8 +263,7 @@ unsigned long __init dom0_compute_nr_pages(
avail -= max_pdx >> s;
}
-need_paging = is_hvm_domain(d) &&
-(!iommu_hap_pt_share || !paging_mode_hap(d));
+need_paging = is_hvm_domain(d);
for ( ; ; need_paging = false )
{
nr_pages = dom0_nrpages;
--
2.13.5 (Apple Git-94)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 03/22] xl: parsing code movement
Roger Pau Monne writes ("[PATCH v3 03/22] xl: parsing code movement"):
> Code movement in preparation for making the bootloader,
> bootloader_args, nested_hvm and timer_mode fields shared between all
> guests types. While moving the code, limit the line-length to 80
> columns.
>
> No functional change.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 04/22] libxl/xl: use the new domain_build_info fields position
Roger Pau Monne writes ("[PATCH v3 04/22] libxl/xl: use the new
domain_build_info fields position"):
> This is required because those options will be used by the new PVH
> guest type, and thus need to be shared between PV and HVM.
This LGTM but the title of this patch has poor grammar.
I think you meant
use the new location of domain_build_info fields
?
Anyway,
Acked-by: Ian Jackson
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 02/22] libxl: introduce a way to mark fields as deprecated in the idl
Roger Pau Monne writes ("[PATCH v3 02/22] libxl: introduce a way to mark fields
as deprecated in the idl"):
> The deprecation involves generating a function that copies the
> deprecated fields into it's new location if the new location has not
> been set.
...
> Changes since v2:
> - Dispose deprecated fields and set them to the default value.
> - Return error if both the deprecated and the new fields are not set to
>non-default values.
Acked-by: Ian Jackson
(mostly based on reading the generated code, which LGTM)
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 2/3] x86/xen/time: setup vcpu 0 time info page
On 27/09/17 15:46, Joao Martins wrote: > In order to support pvclock vdso on xen we need to setup the time > info page for vcpu 0 and register the page with Xen using the > VCPUOP_register_vcpu_time_memory_area hypercall. This hypercall > will also forcefully update the pvti which will set some of the > necessary flags for vdso. Afterwards we check if it supports the > PVCLOCK_TSC_STABLE_BIT flag which is mandatory for having > vdso/vsyscall support. And if so, it will set the cpu 0 pvti that > will be later on used when mapping the vdso image. > > The xen headers are also updated to include the new hypercall for > registering the secondary vcpu_time_info struct. > > Signed-off-by: Joao Martins Reviewed-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 05/22] xl: introduce a domain type option
Roger Pau Monne writes ("[PATCH v3 05/22] xl: introduce a domain type option"):
> Introduce a new type option to xl configuration files in order to
> specify the domain type. This supersedes the current builder option.
>
> The new option is documented in the xl.cfg man page, and the previous
> builder option is marked as deprecated.
Acked-by: Ian Jackson
Although,
> +#define CHECK_AND_SET_TYPE(type, new) \
> +({ \
personally I would prefer the ({ on the previous line, and anyway, I
think you could probably avoid this macro by using a temporary here:
> +/* Deprecated since Xen 4.10. */
> +if (!xlu_cfg_get_string(config, "builder", &buf, 0)) {
> +if (c_info->type == LIBXL_DOMAIN_TYPE_INVALID)
> +fprintf(stderr,
> +"The \"builder\" option is being deprecated, please use \"type\"
> instead.\n");
> +if (!strncmp(buf, "hvm", strlen(buf)))
> +CHECK_AND_SET_TYPE(c_info->type, LIBXL_DOMAIN_TYPE_HVM);
+type_from_builder = LIBXL_DOMAIN_TYPE_HVM;
> +else if (!strncmp(buf, "generic", strlen(buf)))
> +CHECK_AND_SET_TYPE(c_info->type, LIBXL_DOMAIN_TYPE_PV);
> +else {
> +fprintf(stderr, "Invalid domain type %s.\n", buf);
> +exit(1);
> +}
+ if (c_info->type != LIBXL_DOMAIN_TYPE_INVALID &&
+ c_info->type != type_from_builder) {
Up to you, though. I won't insist on this change. Hence my ack.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 06/22] xl: introduce a firmware option
Roger Pau Monne writes ("[PATCH v3 06/22] xl: introduce a firmware option"):
> The new firmware option aims to provide a coherent way to set the
> firmware for the different kind of guests Xen supports.
>
> For PV guests the available firmwares are pvgrub{32|64}, and for HVM
> the following are supported: bios, uefi, seabios, rombios and ovmf.
> Note that uefi maps to ovmf, and bios maps to the default firmware for
> each device model.
Acked-by: Ian Jackson
It's a rather odd that this firmware type field is a string rather
than an enum.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 08/22] libxl: allow PVH guests to use a bootloader
Roger Pau Monne writes ("[PATCH v3 08/22] libxl: allow PVH guests to use a
bootloader"):
> Allow PVH guests to boot using a bootloader.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 07/22] libxl: introduce a PVH guest type
Roger Pau Monne writes ("[PATCH v3 07/22] libxl: introduce a PVH guest type"):
> The new guest type is introduced to the libxl IDL. libxl__domain_make
> is also modified to save the guest type, and libxl__domain_type is
> expanded to fetch that information when detecting guest type.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 09/22] libxl: set PVH guests to use the PV console
Roger Pau Monne writes ("[PATCH v3 09/22] libxl: set PVH guests to use the PV
console"):
> Signed-off-by: Roger Pau Monné
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/pvh: fix PVHv2 Dom0 memory calculation
>>> On 27.09.17 at 16:16, wrote:
> --- a/xen/arch/x86/dom0_build.c
> +++ b/xen/arch/x86/dom0_build.c
> @@ -263,8 +263,7 @@ unsigned long __init dom0_compute_nr_pages(
> avail -= max_pdx >> s;
> }
>
> -need_paging = is_hvm_domain(d) &&
> -(!iommu_hap_pt_share || !paging_mode_hap(d));
> +need_paging = is_hvm_domain(d);
> for ( ; ; need_paging = false )
> {
> nr_pages = dom0_nrpages;
Still in context above is the calculation for IOMMU page tables
When iommu_hap_pt_share, why do we need to reserve extra
space? If the IOMMU calculation isn't precise enough, perhaps
that's what wants changing? Quite possibly it would suffice to
simply double the value dom0_paging_pages() returns in that
case.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 01/12] x86/mm: allow a privileged PV domain to map guest mfns
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 27 September 2017 14:31
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: RE: [PATCH v7 01/12] x86/mm: allow a privileged PV domain to map
> guest mfns
>
> >>> On 27.09.17 at 14:49, wrote:
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 27 September 2017 13:47
> >> To: Paul Durrant
> >> Cc: Andrew Cooper ; xen-
> >> de...@lists.xenproject.org
> >> Subject: RE: [PATCH v7 01/12] x86/mm: allow a privileged PV domain to
> map
> >> guest mfns
> >>
> >> >>> On 27.09.17 at 13:18, wrote:
> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >> Sent: 25 September 2017 14:03
> >> >> >>> On 18.09.17 at 17:31, wrote:
> >> >> > -if ( (real_pg_owner == NULL) || (pg_owner == l1e_owner) ||
> >> >> > +if ( (real_pg_owner == NULL) ||
> >> >> > xsm_priv_mapping(XSM_TARGET, pg_owner,
> real_pg_owner) )
> >> >> > {
> >> >> > gdprintk(XENLOG_WARNING,
> >> >>
> >> >> I'm concerned of the effect of the change on the code paths
> >> >> which you're not really interested in: alloc_l1_table(),
> >> >> ptwr_emulated_update(), and shadow_get_page_from_l1e() all
> >> >> explicitly pass both domains identical, and are now suddenly able
> >> >> to do things they weren't supposed to do. A similar concern
> >> >> applies to __do_update_va_mapping() calling mod_l1_table().
> >> >>
> >> >> I therefore wonder whether the solution to your problem
> >> >> wouldn't rather be MMU_FOREIGN_PT_UPDATE (name subject
> >> >> to improvement suggestions). This at the same time would
> >> >> address my concern regarding the misleading DOMID_SELF
> >> >> passing when really a foreign domain's page is meant.
> >> >
> >> > Looking at this I wonder whether a cleaner solution would be to
> introduce a
> >> > new domid: DOMID_ANY. This meaning of this would be along the same
> >> sort of
> >> > lines as DOMID_XEN or DOMID_IO and would be used in mmu_update
> to
> >> mean 'any
> >> > page over which the caller has privilege'. Does that sound reasonable?
> >>
> >> Not really, no. Even if the caller has privilege over multiple domains,
> >> it should still specify which one it means. Otherwise we may end up
> >> with a page transferring ownership behind its back, and it doing
> >> something to one domain which was meant to be done to another.
> >>
> >
> > Ok, I'll claim the final cmd value then.
>
> Final? We've got 5 left (for a total of 3 bits) afaict.
Really? Maybe I misread... looks like only 2 bits to me.
Paul
>
> Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 10/22] libxl: add PVH support to domain creation
Roger Pau Monne writes ("[PATCH v3 10/22] libxl: add PVH support to domain
creation"):
> Remove the device model "none" support from domain creation and
> introduce support for PVH.
This is a backwards-incompatible change, which at the very least
requires justification. The facility seems to have been introduced in
libxl: allow the creation of HVM domains without a device model.
5ca88cb7582a19636646c1a39c739fdbcaf3362a
which was part of the original PVH2 work, I think. I'm not sure how
explicitly we need to have marked the interface as unstable but we
probably did somewhere. Perhaps you could introduce an appropriate
reference in the commit message ?
The code changes seem fine to me.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] Call xen_cleanhighmap() with 4MB aligned for page tables mapping
On 27/09/17 15:38, Boris Ostrovsky wrote: > On 09/27/2017 05:43 AM, Juergen Gross wrote: >> On 27/09/17 11:41, Zhenzhong Duan wrote: >>> When bootup a PVM guest with large memory(Ex.240GB), XEN provided initial >>> mapping overlaps with kernel module virtual space. When mapping in this >>> space >>> is cleared by xen_cleanhighmap(), in certain case there could be an 2MB >>> mapping >>> left. This is due to XEN initialize 4MB aligned mapping but >>> xen_cleanhighmap() >>> finish at 2MB boundary. > > Does this mapping need to be 4MB-aligned? I guess you are questioning the alignment of addr to be 4MB? In this case you are right: the end of the mapping is 4MB aligned, as correctly stated in the comment added. > (I also think this should go to stable trees) Indeed. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 15/22] libxl: add PVH support to vpcu hotplug, domain destruction/pause and domain configuration
Roger Pau Monne writes ("[PATCH v3 15/22] libxl: add PVH support to vpcu
hotplug, domain destruction/pause and domain configuration"):
> And remove support for device model "none".
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 11/22] libxl: remove device model "none" support from disk related functions
Roger Pau Monne writes ("[PATCH v3 11/22] libxl: remove device model "none"
support from disk related functions"):
> CD-ROM backend selection was partially based on the device model, this
> is no longer needed since the device model "none" is now removed, so
> HVM guests always have a device model.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 12/22] libxl: set device model for PVH guests
Roger Pau Monne writes ("[PATCH v3 12/22] libxl: set device model for PVH
guests"):
> PVH guests use the same device model selection as PV guests, because
> PVH guests only use the device model for the PV backends.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 13/22] libxl: add PVH support to domain building
Roger Pau Monne writes ("[PATCH v3 13/22] libxl: add PVH support to domain
building"):
> And remove device model "none" support.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] RT-Xen on ARM
Hello, On 27.09.17 16:57, Meng Xu wrote: The command is: java -jar carts.jar inputfile outputfile From the next example, I would say the command is: java -jar carts.jar inputfile interface_type outputfile An example command is: java -jar carts.jar 1-1.10-in.xml MPR2 1-1.10-out.xml Thanks a lot. It does work. Could you please clarify a bit more points to me: - As I understand the upstreamed rtds employs gEDF only. Is it correct? - Could you please provide an example input xml for CARTS described a system with 2 RT domains with 2 VCPUs each, running on a 2PCPUs, with gEDF scheduling at VMM level (for XEN based setup). For pEDF at both VMM and domain level, my understanding is that the os_scheduler represents XEN, and VCPUs are represented by components with tasks running on them. - I did not get a concept of min_period/max_period for a component/os_scheduler in CARTS description files. If I have them different, CARTS gives calculation for all periods in between, but did not provide the best period to get system schedulable. -- *Andrii Anisov* ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 17/22] libxl: PVH guests use PV nics
Roger Pau Monne writes ("[PATCH v3 17/22] libxl: PVH guests use PV nics"):
> Remove device model "none" support from the nic functions.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 18/22] libxl: remove device model "none" support from stream functions
Roger Pau Monne writes ("[PATCH v3 18/22] libxl: remove device model "none"
support from stream functions"):
> Remove the usage of device model "none" in the migration stream
> related functions.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 2/3] x86/xen/time: setup vcpu 0 time info page
> +static void xen_setup_vsyscall_time_info(void)
> +{
> + struct vcpu_register_time_memory_area t;
> + struct pvclock_vsyscall_time_info *ti;
> + struct pvclock_vcpu_time_info *pvti;
> + int ret;
> +
> + pvti = &__this_cpu_read(xen_vcpu)->time;
> +
> + /*
> + * We check ahead on the primary time info if this
> + * bit is supported hence speeding up Xen clocksource.
> + */
> + if (!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))
> + return;
> +
> + pvclock_set_flags(PVCLOCK_TSC_STABLE_BIT);
Is it OK to have this flag set if anything below fails?
(I can see in the changelog that apparently at some point I've asked
about this at v1 but I can't remember/find what exactly it was)
-boris
> +
> + ti = (struct pvclock_vsyscall_time_info *)get_zeroed_page(GFP_KERNEL);
> + if (!ti)
> + return;
> +
> + t.addr.v = &ti->pvti;
> +
> + ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t);
> + if (ret) {
> + pr_notice("xen: VCLOCK_PVCLOCK not supported (err %d)\n", ret);
> + free_page((unsigned long)ti);
> + return;
> + }
> +
> + /*
> + * If the check above succedded this one should too since it's the
> + * same data on both primary and secondary time infos just different
> + * memory regions. But we still check it in case hypervisor is buggy.
> + */
> + pvti = &ti->pvti;
> + if (!(pvti->flags & PVCLOCK_TSC_STABLE_BIT)) {
> + t.addr.v = NULL;
> + ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area,
> + 0, &t);
> + if (!ret)
> + free_page((unsigned long)ti);
> +
> + pr_notice("xen: VCLOCK_PVCLOCK not supported (tsc unstable)\n");
> + return;
> + }
> +
> + xen_clock = ti;
> + pvclock_set_pvti_cpu0_va(xen_clock);
> +
> + xen_clocksource.archdata.vclock_mode = VCLOCK_PVCLOCK;
> +}
> +
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 19/22] libxl: add PVH support to USB
Roger Pau Monne writes ("[PATCH v3 19/22] libxl: add PVH support to USB"):
> Add PVH support to usb related functions.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 14/22] libxl: add PVH support to domain save/suspend
Roger Pau Monne writes ("[PATCH v3 14/22] libxl: add PVH support to domain
save/suspend"):
> And remove the device model "none" support.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] libxc: remove stale error check for domain size in xc_sr_save_x86_hvm.c
On Tue, Sep 26, 2017 at 02:02:56PM +0200, Juergen Gross wrote: > Long ago domains to be saved were limited to 1TB size due to the > migration stream v1 limitations which used a 32 bit value for the > PFN and the frame type (4 bits) leaving only 28 bits for the PFN. > > Migration stream V2 uses a 64 bit value for this purpose, so there > is no need to refuse saving (or migrating) domains larger than 1 TB. > > For 32 bit toolstacks there is still a size limit, as domains larger > than about 1TB will lead to an exhausted virtual address space of the > saving process. So keep the test for 32 bit, but don't base it on the > page type macros. As a migration could lead to the situation where a > 32 bit toolstack would have to handle such a large domain (in case the > sending side is 64 bit) the same test should be added for restoring a > domain. > > Signed-off-by: Juergen Gross I will leave this to Andrew. I don't really have an opinion here. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 20/22] libxl: add PVH support to x86 functions
Roger Pau Monne writes ("[PATCH v3 20/22] libxl: add PVH support to x86
functions"):
> This also includes the x86 ACPI related functions. Remove support for
> device model "none"
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 113852: FAIL
flight 113852 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/113852/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu broken in 113844 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-multivcpu 4 host-install(4) broken in 113844 pass in 113852 test-amd64-amd64-xl-pvh-intel 18 guest-localmigrate/x10fail pass in 113844 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail pass in 113844 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail REGR. vs. 113817 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 113817 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 113817 test-amd64-amd64-xl-rtds 10 debian-install fail like 113817 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 113817 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: qemuu31bc1d8481af414cfa2857f905e40f7d8e6d5b2e baseline version: qemuu1e3ee834083227f552179f6e43902cba5a866e6b Last test of basis 113817 2017-09-25 22:47:44 Z1 days Failing since113839 2017-09-26 18:16:50 Z0 days3 attempts Testing same since 113844 2017-09-27 00:18:41 Z0 days2 attempts People who touched revisions under test: Alex Bennée Alistair Francis Daniel P. Berrange Eric Blake Fam Zheng John Snow Kamil Rytarowski Kevin Wolf KONRAD Frederic Liang Yan Max Filippov Michael Roth Michael S. Tsirkin Michael Tokarev Peter Maydell Philippe Mathieu-Daudé Richard Henderson Stefan Weil Thomas Huth Vladimir Sementsov-Ogievskiy jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt
Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md
On 9/26/2017 3:12 AM, Dario Faggioli wrote: > [Cc-list modified by removing someone and adding someone else] > > On Mon, 2017-09-25 at 16:10 -0700, Stefano Stabellini wrote: >> On Mon, 11 Sep 2017, George Dunlap wrote: >>> +### RTDS based Scheduler >>> + >>> +Status: Experimental >>> + >>> +A soft real-time CPU scheduler built to provide guaranteed CPU >>> capacity to guest VMs on SMP hosts >>> + >>> +### ARINC653 Scheduler >>> + >>> +Status: Supported, Not security supported >>> + >>> +A periodically repeating fixed timeslice scheduler. Multicore >>> support is not yet implemented. >>> + >>> +### Null Scheduler >>> + >>> +Status: Experimental >>> + >>> +A very simple, very static scheduling policy >>> +that always schedules the same vCPU(s) on the same pCPU(s). >>> +It is designed for maximum determinism and minimum overhead >>> +on embedded platforms. >> >> Hi all, >> > Hey! > >> I have just noticed that none of the non-credit schedulers are >> security >> supported. Would it make sense to try to support at least one of >> them? >> > Yes, that indeed would be great. > >> For example, RTDS is not new and Dario is co-maintaining it. It is >> currently marked as Supported in the MAINTAINERS file. Is it really >> fair >> to mark it as "Experimental" in SUPPORT.md? >> > True, but there still one small missing piece in RTDS, before I'd feel > comfortable about telling people "here, it's ready, use it at will", > which is the work conserving mode. > > There are patches out for this, and they were posted before last > posting date, so, in theory, they still can go in 4.10. > >> The Null scheduler was new when we started this discussion, but now >> that >> Xen 4.10 is entering code freeze, Null scheduler is not so new >> anymore. >> We didn't get any bug reports during the 4.10 development window. By >> the >> time this document is accepted and Xen 4.10 is out, Null could be a >> candidate for "Supported" too. >> > Yes, especially considering how simple it is, there should be no big > issues preventing that to happen. > > There's one thing, though: it's not tested in OSSTest. I can actually > try to have a quick look about creating a job that does that (I mean > like today). > > The trickiest part is the need to limit the number of Dom0 vCPUs, to a > number that would allow the creation and the local migration of guests > (considering that the number of pCPUs of the testbox in the MA colo > varies, and that we have some ARM boards with like 1 or 2 CPUs). > > > Actually, the best candidate for gaining security support, is IMO > ARINC. Code is also rather simple and "stable" (hasn't changed in the > last... years!) and it's used by DornerWorks' people for some of their > projects (I think?). It's also not tested in OSSTest, though, and > considering how special purpose it is, I think we're not totally > comfortable marking it as Sec-Supported, without feedback from the > maintainers. > > George, Josh, Robert? > Yes, we do still use the ARINC653 scheduler. Since it is so simple, it hasn't really needed any modifications in the last couple years. We are not really sure what kind of feedback you are looking from us in regards to marking it sec-supported, but would be happy to try and answer any questions. If you have any specific questions or requests, we can discuss it internally and get back to you. Thanks, Robbie VanVossen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 21/22] xl: add PVH as a guest type
Roger Pau Monne writes ("[PATCH v3 21/22] xl: add PVH as a guest type"):
> And remove device model "none".
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 01/12] x86/mm: allow a privileged PV domain to map guest mfns
>>> On 27.09.17 at 16:22, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 27 September 2017 14:31 >> >>> On 27.09.17 at 14:49, wrote: >> > Ok, I'll claim the final cmd value then. >> >> Final? We've got 5 left (for a total of 3 bits) afaict. > > Really? Maybe I misread... looks like only 2 bits to me. Maybe you and I looked in different places. I'm deriving this from cmd = req.ptr & (sizeof(l1_pgentry_t)-1); switch ( cmd ) in do_mmu_update(). Only 32-bit non-PAE guests would have been limited to 2 bits. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 22/22] libxl: remove device model "none" from IDL
Roger Pau Monne writes ("[PATCH v3 22/22] libxl: remove device model "none"
from IDL"):
> And the xl.cfg man page documentation.
See my comments about the start of the abolition of "none" as devicd
model. I have acked the intermediate patches.
Feel free to put the explanation for the unceremonious dropping of
this support in whatever commit messages(s) seem appropriate.
(It is interesting to note how much easier this all is because "none"
was never properly supported. If it had been, then we would need much
more careful sequencing of all this work, and also backward
compatibility.)
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 16/22] libxl: add PVH support to memory functions
Roger Pau Monne writes ("[PATCH v3 16/22] libxl: add PVH support to memory
functions"):
> Signed-off-by: Roger Pau Monné
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] Call xen_cleanhighmap() with 4MB aligned for page tables mapping
On 09/27/2017 10:33 AM, Juergen Gross wrote: > On 27/09/17 15:38, Boris Ostrovsky wrote: >> On 09/27/2017 05:43 AM, Juergen Gross wrote: >>> On 27/09/17 11:41, Zhenzhong Duan wrote: When bootup a PVM guest with large memory(Ex.240GB), XEN provided initial mapping overlaps with kernel module virtual space. When mapping in this space is cleared by xen_cleanhighmap(), in certain case there could be an 2MB mapping left. This is due to XEN initialize 4MB aligned mapping but xen_cleanhighmap() finish at 2MB boundary. >> Does this mapping need to be 4MB-aligned? > I guess you are questioning the alignment of addr to be 4MB? > In this case you are right: the end of the mapping is 4MB aligned, as > correctly stated in the comment added. Yes, and my question is why does it need to be aligned on 4MB. Doesn't 2MB alignment suffice? -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 01/12] x86/mm: allow a privileged PV domain to map guest mfns
> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan > Beulich > Sent: 27 September 2017 15:42 > To: Paul Durrant > Cc: Andrew Cooper ; xen- > de...@lists.xenproject.org > Subject: Re: [Xen-devel] [PATCH v7 01/12] x86/mm: allow a privileged PV > domain to map guest mfns > > >>> On 27.09.17 at 16:22, wrote: > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: 27 September 2017 14:31 > >> >>> On 27.09.17 at 14:49, wrote: > >> > Ok, I'll claim the final cmd value then. > >> > >> Final? We've got 5 left (for a total of 3 bits) afaict. > > > > Really? Maybe I misread... looks like only 2 bits to me. > > Maybe you and I looked in different places. I'm deriving this from > > cmd = req.ptr & (sizeof(l1_pgentry_t)-1); > > switch ( cmd ) > > in do_mmu_update(). Only 32-bit non-PAE guests would have been > limited to 2 bits. Ah, ok. I was going off what it says in the header, where the comments state that [0:1] are command bits and [:2] are address bits, but for 64-bit or PAE guests then it makes sense that bit 2 is up for grabs. Anyway I can use 3, which still fits in bits [0:1]. Paul > > Jan > > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] Call xen_cleanhighmap() with 4MB aligned for page tables mapping
On 27/09/17 16:48, Boris Ostrovsky wrote: > On 09/27/2017 10:33 AM, Juergen Gross wrote: >> On 27/09/17 15:38, Boris Ostrovsky wrote: >>> On 09/27/2017 05:43 AM, Juergen Gross wrote: On 27/09/17 11:41, Zhenzhong Duan wrote: > When bootup a PVM guest with large memory(Ex.240GB), XEN provided initial > mapping overlaps with kernel module virtual space. When mapping in this > space > is cleared by xen_cleanhighmap(), in certain case there could be an 2MB > mapping > left. This is due to XEN initialize 4MB aligned mapping but > xen_cleanhighmap() > finish at 2MB boundary. >>> Does this mapping need to be 4MB-aligned? >> I guess you are questioning the alignment of addr to be 4MB? >> In this case you are right: the end of the mapping is 4MB aligned, as >> correctly stated in the comment added. > > Yes, and my question is why does it need to be aligned on 4MB. Doesn't > 2MB alignment suffice? I believe this has historical reasons. :-) For this patch the answer doesn't matter, as Xen does it this way and the kernel has to cope with the situation. This interface is specified in include/xen/interface/xen.h in the comment section just before struct start_info: /* * Start-of-day memory layout * * 1. The domain is started within contiguous virtual-memory region. * 2. The contiguous region begins and ends on an aligned 4MB boundary. ... Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] Call xen_cleanhighmap() with 4MB aligned for page tables mapping
On 09/27/2017 10:56 AM, Juergen Gross wrote: > On 27/09/17 16:48, Boris Ostrovsky wrote: >> On 09/27/2017 10:33 AM, Juergen Gross wrote: >>> On 27/09/17 15:38, Boris Ostrovsky wrote: On 09/27/2017 05:43 AM, Juergen Gross wrote: > On 27/09/17 11:41, Zhenzhong Duan wrote: >> When bootup a PVM guest with large memory(Ex.240GB), XEN provided initial >> mapping overlaps with kernel module virtual space. When mapping in this >> space >> is cleared by xen_cleanhighmap(), in certain case there could be an 2MB >> mapping >> left. This is due to XEN initialize 4MB aligned mapping but >> xen_cleanhighmap() >> finish at 2MB boundary. Does this mapping need to be 4MB-aligned? >>> I guess you are questioning the alignment of addr to be 4MB? >>> In this case you are right: the end of the mapping is 4MB aligned, as >>> correctly stated in the comment added. >> Yes, and my question is why does it need to be aligned on 4MB. Doesn't >> 2MB alignment suffice? > I believe this has historical reasons. :-) > > For this patch the answer doesn't matter, as Xen does it this way and > the kernel has to cope with the situation. > > This interface is specified in include/xen/interface/xen.h in the > comment section just before struct start_info: > > /* > * Start-of-day memory layout > * > * 1. The domain is started within contiguous virtual-memory region. > * 2. The contiguous region begins and ends on an aligned 4MB boundary. Ah, this is what I was really looking for --- that 4MB alignment is part of the ABI. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] Call xen_cleanhighmap() with 4MB aligned for page tables mapping
On 27/09/17 15:56, Juergen Gross wrote: > On 27/09/17 16:48, Boris Ostrovsky wrote: >> On 09/27/2017 10:33 AM, Juergen Gross wrote: >>> On 27/09/17 15:38, Boris Ostrovsky wrote: On 09/27/2017 05:43 AM, Juergen Gross wrote: > On 27/09/17 11:41, Zhenzhong Duan wrote: >> When bootup a PVM guest with large memory(Ex.240GB), XEN provided initial >> mapping overlaps with kernel module virtual space. When mapping in this >> space >> is cleared by xen_cleanhighmap(), in certain case there could be an 2MB >> mapping >> left. This is due to XEN initialize 4MB aligned mapping but >> xen_cleanhighmap() >> finish at 2MB boundary. Does this mapping need to be 4MB-aligned? >>> I guess you are questioning the alignment of addr to be 4MB? >>> In this case you are right: the end of the mapping is 4MB aligned, as >>> correctly stated in the comment added. >> Yes, and my question is why does it need to be aligned on 4MB. Doesn't >> 2MB alignment suffice? > I believe this has historical reasons. :-) Back in the day, superpages had 4M alignment. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/pvh: fix PVHv2 Dom0 memory calculation
On Wed, Sep 27, 2017 at 02:26:37PM +, Jan Beulich wrote:
> >>> On 27.09.17 at 16:16, wrote:
> > --- a/xen/arch/x86/dom0_build.c
> > +++ b/xen/arch/x86/dom0_build.c
> > @@ -263,8 +263,7 @@ unsigned long __init dom0_compute_nr_pages(
> > avail -= max_pdx >> s;
> > }
> >
> > -need_paging = is_hvm_domain(d) &&
> > -(!iommu_hap_pt_share || !paging_mode_hap(d));
> > +need_paging = is_hvm_domain(d);
> > for ( ; ; need_paging = false )
> > {
> > nr_pages = dom0_nrpages;
>
> Still in context above is the calculation for IOMMU page tables
> When iommu_hap_pt_share, why do we need to reserve extra
> space? If the IOMMU calculation isn't precise enough, perhaps
> that's what wants changing? Quite possibly it would suffice to
> simply double the value dom0_paging_pages() returns in that
> case.
I have not seen this issue myself, perhaps Boris can provide a little
more context on how to trigger this, so that the cause can be narrowed
down.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 2/3] x86/xen/time: setup vcpu 0 time info page
On 09/27/2017 03:40 PM, Boris Ostrovsky wrote:
>> +static void xen_setup_vsyscall_time_info(void)
>> +{
>> +struct vcpu_register_time_memory_area t;
>> +struct pvclock_vsyscall_time_info *ti;
>> +struct pvclock_vcpu_time_info *pvti;
>> +int ret;
>> +
>> +pvti = &__this_cpu_read(xen_vcpu)->time;
>> +
>> +/*
>> + * We check ahead on the primary time info if this
>> + * bit is supported hence speeding up Xen clocksource.
>> + */
>> +if (!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))
>> +return;
>> +
>> +pvclock_set_flags(PVCLOCK_TSC_STABLE_BIT);
>
> Is it OK to have this flag set if anything below fails?
>
Yes - if anything below fails it will only affect userspace mapped page. What I
do above is just allowing xen clocksource to use/check that bit (consequently
speeding up sched_clock) given the necessary support is there in the master
copy. The secondary copy (i.e. what's being set up below, mapped/used in vdso)
has the same data from the master copy, just separate memory regions. The checks
below are just for the unlikely cases of failing to register the secondary copy
or if its content were to differ from master copy in future releases - and
therefore we handle those more gracefully.
> (I can see in the changelog that apparently at some point I've asked
> about this at v1 but I can't remember/find what exactly it was)
>
>> +
>> +ti = (struct pvclock_vsyscall_time_info *)get_zeroed_page(GFP_KERNEL);
>> +if (!ti)
>> +return;
>> +
>> +t.addr.v = &ti->pvti;
>> +
>> +ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t);
>> +if (ret) {
>> +pr_notice("xen: VCLOCK_PVCLOCK not supported (err %d)\n", ret);
>> +free_page((unsigned long)ti);
>> +return;
>> +}
>> +
>> +/*
>> + * If the check above succedded this one should too since it's the
>> + * same data on both primary and secondary time infos just different
>> + * memory regions. But we still check it in case hypervisor is buggy.
>> + */
>> +pvti = &ti->pvti;
>> +if (!(pvti->flags & PVCLOCK_TSC_STABLE_BIT)) {
>> +t.addr.v = NULL;
>> +ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area,
>> + 0, &t);
>> +if (!ret)
>> +free_page((unsigned long)ti);
>> +
>> +pr_notice("xen: VCLOCK_PVCLOCK not supported (tsc unstable)\n");
>> +return;
>> +}
>> +
>> +xen_clock = ti;
>> +pvclock_set_pvti_cpu0_va(xen_clock);
>> +
>> +xen_clocksource.archdata.vclock_mode = VCLOCK_PVCLOCK;
>> +}
>> +
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 10/22] libxl: add PVH support to domain creation
On Wed, Sep 27, 2017 at 02:28:11PM +, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v3 10/22] libxl: add PVH support to domain
> creation"):
> > Remove the device model "none" support from domain creation and
> > introduce support for PVH.
>
> This is a backwards-incompatible change, which at the very least
> requires justification. The facility seems to have been introduced in
>
> libxl: allow the creation of HVM domains without a device model.
> 5ca88cb7582a19636646c1a39c739fdbcaf3362a
>
> which was part of the original PVH2 work, I think. I'm not sure how
> explicitly we need to have marked the interface as unstable but we
> probably did somewhere. Perhaps you could introduce an appropriate
> reference in the commit message ?
I cannot find any written down references to the interface being
unstable, I think it was mostly based on me replying to people on the
mailing list saying that this interface was not stable, and that
people shouldn't rely on it.
But is this a backwards incompatible change? By removing
LIBXL_HAVE_DEVICE_MODEL_VERSION_NONE there should be no breakage to
libxl downstreams, as long as they used the macro properly.
Let me reply to patch 10 with an expanded commit message.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 3/3] MAINTAINERS: xen, kvm: track pvclock-abi.h changes
On Wed, Sep 27, 2017 at 02:46:23PM +0100, Joao Martins wrote: > This file defines an ABI shared between guest and hypervisor(s) > (KVM, Xen) and as such there should be an correspondent entry in > MAINTAINERS file. Notice that there's already a text notice at the > top of the header file, hence this commit simply enforces it more > explicitly and have both peers noticed when such changes happen. > > Signed-off-by: Joao Martins > Acked-by: Juergen Gross Reviewed-by: Konrad Rzeszutek Wilk > --- > In the end, I choose the originally posted because this is so far the > only ABI shared between Xen/KVM. Therefore whenever we have more things > shared it would deserve its own place in MAINTAINERS file. If the > thinking is wrong, I can switch to the alternative with a > "PARAVIRT ABIS" section. > > Changes since v1: > * Add Juergen Gross Acked-by. > --- > MAINTAINERS | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 6671f375f7fc..a4834c3c377a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7603,6 +7603,7 @@ S: Supported > F: arch/x86/kvm/ > F: arch/x86/include/uapi/asm/kvm* > F: arch/x86/include/asm/kvm* > +F: arch/x86/include/asm/pvclock-abi.h > F: arch/x86/kernel/kvm.c > F: arch/x86/kernel/kvmclock.c > > @@ -14718,6 +14719,7 @@ F:arch/x86/xen/ > F: drivers/*/xen-*front.c > F: drivers/xen/ > F: arch/x86/include/asm/xen/ > +F: arch/x86/include/asm/pvclock-abi.h > F: include/xen/ > F: include/uapi/xen/ > F: Documentation/ABI/stable/sysfs-hypervisor-xen > -- > 2.11.0 > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 10/22] libxl: add PVH support to domain creation
On Wed, Sep 27, 2017 at 02:28:11PM +, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v3 10/22] libxl: add PVH support to domain
> creation"):
> > Remove the device model "none" support from domain creation and
> > introduce support for PVH.
>
> This is a backwards-incompatible change, which at the very least
> requires justification. The facility seems to have been introduced in
>
> libxl: allow the creation of HVM domains without a device model.
> 5ca88cb7582a19636646c1a39c739fdbcaf3362a
>
> which was part of the original PVH2 work, I think. I'm not sure how
> explicitly we need to have marked the interface as unstable but we
> probably did somewhere. Perhaps you could introduce an appropriate
> reference in the commit message ?
What about adding:
Setting device model to none was never supported since it was an
unstable interface used while transitioning from PVHv1 to PVHv2.
Now that PVHv1 has been finally removed and that a supported
interface for PVHv2 is being added this option is no longer necessary,
hence it's removed.
I can also add:
It might be possible to re-introduce it in the future with a proper
implementation, in order to create a HVM guest without a device model,
which is slightly different from a PVHv2 guest.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen-hvm: use errno in error message
The error code is encoding in errno, not rc.
Signed-off-by: Wei Liu
---
Cc: Stefano Stabellini
Cc: Anthony PERARD
---
hw/i386/xen/xen-hvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index d9ccd5d0d6..f79816a649 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -1446,7 +1446,7 @@ void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t
length)
if (rc) {
fprintf(stderr,
"%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n",
-__func__, start, nb_pages, rc, strerror(-rc));
+__func__, start, nb_pages, rc, strerror(errno));
}
}
}
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen-hvm: use errno in error message
On Wed, Sep 27, 2017 at 05:10:09PM +0100, Wei Liu wrote: > The error code is encoding in errno, not rc. > "is encoded", sorry for the typo... ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen-hvm: use errno in error message
On Wed, Sep 27, 2017 at 05:10:09PM +0100, Wei Liu wrote:
> The error code is encoding in errno, not rc.
^ encoded
I think.
Otherwise,
Reviewed-by: Anthony PERARD
Thanks,
>
> Signed-off-by: Wei Liu
> ---
> Cc: Stefano Stabellini
> Cc: Anthony PERARD
> ---
> hw/i386/xen/xen-hvm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
> index d9ccd5d0d6..f79816a649 100644
> --- a/hw/i386/xen/xen-hvm.c
> +++ b/hw/i386/xen/xen-hvm.c
> @@ -1446,7 +1446,7 @@ void xen_hvm_modified_memory(ram_addr_t start,
> ram_addr_t length)
> if (rc) {
> fprintf(stderr,
> "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i,
> %s\n",
> -__func__, start, nb_pages, rc, strerror(-rc));
> +__func__, start, nb_pages, rc, strerror(errno));
> }
> }
> }
> --
> 2.11.0
>
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/pvh: fix PVHv2 Dom0 memory calculation
On 09/27/2017 11:10 AM, Roger Pau Monné wrote:
> On Wed, Sep 27, 2017 at 02:26:37PM +, Jan Beulich wrote:
> On 27.09.17 at 16:16, wrote:
>>> --- a/xen/arch/x86/dom0_build.c
>>> +++ b/xen/arch/x86/dom0_build.c
>>> @@ -263,8 +263,7 @@ unsigned long __init dom0_compute_nr_pages(
>>> avail -= max_pdx >> s;
>>> }
>>>
>>> -need_paging = is_hvm_domain(d) &&
>>> -(!iommu_hap_pt_share || !paging_mode_hap(d));
>>> +need_paging = is_hvm_domain(d);
>>> for ( ; ; need_paging = false )
>>> {
>>> nr_pages = dom0_nrpages;
>> Still in context above is the calculation for IOMMU page tables
>> When iommu_hap_pt_share, why do we need to reserve extra
>> space? If the IOMMU calculation isn't precise enough, perhaps
>> that's what wants changing? Quite possibly it would suffice to
>> simply double the value dom0_paging_pages() returns in that
>> case.
> I have not seen this issue myself, perhaps Boris can provide a little
> more context on how to trigger this, so that the cause can be narrowed
> down.
I could only trigger this on one of my machines but essentially the
problem was that we reserved memory for page tables
(pvh_setup_p2m()->paging_set_allocation()) and this reservation was not
accounted for when trying to populate dom0's e820.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 113855: tolerable FAIL - PUSHED
flight 113855 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/113855/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 113845 pass in 113855 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 113845 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-win7-amd64 18 guest-start/win.repeat fail blocked in 113823 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 113845 blocked in 113823 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 113845 blocked in 113823 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 113823 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 113823 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 113823 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 113823 test-amd64-amd64-xl-rtds 10 debian-install fail like 113823 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 113823 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 113823 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: linuxdc972a67cc54585bd83ad811c4e9b6ab3dcd427e baseline version: linuxe365806ac289457263a133bd32df8df49897f612 Last test of basis 113823 2017-09-26 08:36:21 Z1 days Testing same since 113845 2017-09-27 00:20:16 Z0 days2 attempts People who touched revisions under test: Adrian Hunter Andreas Gruenbacher Linus Torvalds Ulf Hansson Wolfram Sang jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf
