Re: [Xen-devel] [PATCH] build: add --with-rundir option to configure
On 22/02/17 07:53, Juergen Gross wrote: > On 20/02/17 16:19, Andrew Cooper wrote: >> On 20/02/17 14:43, Juergen Gross wrote: >>> On 20/02/17 15:31, Wei Liu wrote: On Thu, Feb 16, 2017 at 08:47:07AM +0100, Juergen Gross wrote: > There have been reports that Fedora 25 uses /run instead of /var/run. > > Add a --with-rundir option ito configure to be able to specify that I've read this thread but I'm not sure if I need to take any action or all the comments addressed -- especially the part about autoconf. >>> Andrew, are you fine with my answer regarding autoconf? Or do you have >>> some information regarding --runstatedir which could help? >> Oh sorry. Didn't realise I was blocking here. I have no specific >> information, other than the quick search I did. >> >> Can't the future problem be worked around just with if autoconf version >> < 2.70 ? > I don't think it is possible to add configure options other than > --disable-*, --enable-*, --with-* or --without-* by other means than > patching general.m4 of autoconf. I don't think we want to do that. Ok. In which case lets go with 3). ~Andrew > > So the possibilities are: > > 1. don't support /run instead of /var/run via configure > 2. patch autoconf to support --runstatedir > 3. take this patch adding support via --with-rundir and possibly >switch over to --runstatedir when a new autoconf version is >available > > I'm in favor of (3.). > > > Juergen > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 04/10] x86/cpuid: Handle leaf 0x4 in guest_cpuid()
On 22/02/17 07:23, Jan Beulich wrote:
On 21.02.17 at 18:35, wrote:
>> On 21/02/17 17:16, Jan Beulich wrote:
>> On 20.02.17 at 12:00, wrote:
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -163,6 +163,9 @@ static void recalculate_xstate(struct cpuid_policy *p)
*/
static void recalculate_misc(struct cpuid_policy *p)
{
+/* Leaves with subleaf unions. */
+p->basic.raw[0x4] = p->basic.raw[0x7] = p->basic.raw[0xd] =
EMPTY_LEAF;
>>> How come you play with leaves 7 and 0xd here?
>> This particular piece of clobbering was something which has only just
>> occurred to me now when implementing the leaf 4 union.
>>
>> Then again, there is no supported way of getting any values into those
>> particular rows, or reading out of them, so I could just rely on no-one
>> caring?
> Well, if they start out as EMPTY_LEAF and there's no way to get
> other values into them, why bother filling them here? The more
> with a line that doesn't allow neatly extending should one more
> such leaf need adding here. I'd say if you want to clobber the
> values here just in case, merge the assignments above (in
> numeric order) with the ones that are already there just below
> (visible in the original patch context).
I will just drop the clobbering. Even this bit of logic isn't going to
survive to the end of eventual toolstack changes.
>
@@ -244,6 +248,25 @@ static void __init calculate_raw_policy(void)
cpuid_leaf(i, &p->basic.raw[i]);
}
+if ( p->basic.max_leaf >= 4 )
+{
+for ( i = 0; i < ARRAY_SIZE(p->cache.raw); ++i )
+{
+cpuid_count_leaf(4, i, &p->cache.raw[i]);
+
+if ( p->cache.subleaf[i].type == 0 )
+break;
+}
+
+/*
+ * The choice of CPUID_GUEST_NR_CACHE is arbitrary. It is
expected
+ * that it will eventually need increasing for future hardware.
+ */
+if ( i == ARRAY_SIZE(p->cache.raw) )
+printk(XENLOG_WARNING
+ "CPUID: Insufficient Leaf 4 space for this
hardware\n");
+}
>>> It probably doesn't hurt, but it's one off: There's no enough space
>>> only when the next (i-th) doesn't report type 0.
>> This bit of logic is slightly awkward. We read into p->cache.raw[i]
>> before looking to see whether p->cache.subleaf[i].type is the end of the
>> list. As such we always read one-past-the-end.
> Sure. Issuing the message prematurely could of course be avoided
> nevertheless, by reading sub-leaf i (regardless of whether i ==
> CPUID_GUEST_NR_CACHE) into a local variable and checking type
> there. But as said, it's not something I strictly ask for to be done,
> as I can also see upsides of seeing this warning earlier than
> absolutely needed.
Ok. I will leave it as-is.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes
>>> On 22.02.17 at 08:47, wrote: > On 02/22/2017 09:40 AM, Jan Beulich wrote: > On 22.02.17 at 08:16, wrote: >>> 3. C89 - Jan, we discussed that a bit for zero-sized arrays [2] >>> and empty structures [3]. So, then we came to a conclusion that >>> breakage is not acceptable, but now I see that you have changed >>> your mind? (Please correct me if I got it wrong). The reason I am >>> bringing this back to life is that sndif and displif protocols >>> use grefs[1] construct, while originally I was about to avoid that "1". >>> So, as now Stefano introduces *grant_ref_t ref[];* I would also >>> like to change sndif/displif to use the same. Do you think it can be >>> done this time? >> I don't think so, no. Please pay close attention to the reason why I >> think an exception is fine in the case here, but not there: Someone >> including ring.h without actively using the new macro will not see a >> compile failure. Someone including sndif.h, otoh, would afaict. > fair enough, but it means that those who want to use > PV calls/9pfs will not be able to do so with C89, right? They would need to customize the header to do so, or introduce a variant of the macro Stefano proposes elsewhere. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] build: add --with-rundir option to configure
On 20/02/17 16:19, Andrew Cooper wrote: > On 20/02/17 14:43, Juergen Gross wrote: >> On 20/02/17 15:31, Wei Liu wrote: >>> On Thu, Feb 16, 2017 at 08:47:07AM +0100, Juergen Gross wrote: There have been reports that Fedora 25 uses /run instead of /var/run. Add a --with-rundir option ito configure to be able to specify that >>> I've read this thread but I'm not sure if I need to take any action or >>> all the comments addressed -- especially the part about autoconf. >> Andrew, are you fine with my answer regarding autoconf? Or do you have >> some information regarding --runstatedir which could help? > > Oh sorry. Didn't realise I was blocking here. I have no specific > information, other than the quick search I did. > > Can't the future problem be worked around just with if autoconf version > < 2.70 ? I don't think it is possible to add configure options other than --disable-*, --enable-*, --with-* or --without-* by other means than patching general.m4 of autoconf. I don't think we want to do that. So the possibilities are: 1. don't support /run instead of /var/run via configure 2. patch autoconf to support --runstatedir 3. take this patch adding support via --with-rundir and possibly switch over to --runstatedir when a new autoconf version is available I'm in favor of (3.). Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes
On 02/22/2017 09:40 AM, Jan Beulich wrote: On 22.02.17 at 08:16, wrote: 3. C89 - Jan, we discussed that a bit for zero-sized arrays [2] and empty structures [3]. So, then we came to a conclusion that breakage is not acceptable, but now I see that you have changed your mind? (Please correct me if I got it wrong). The reason I am bringing this back to life is that sndif and displif protocols use grefs[1] construct, while originally I was about to avoid that "1". So, as now Stefano introduces *grant_ref_t ref[];* I would also like to change sndif/displif to use the same. Do you think it can be done this time? I don't think so, no. Please pay close attention to the reason why I think an exception is fine in the case here, but not there: Someone including ring.h without actively using the new macro will not see a compile failure. Someone including sndif.h, otoh, would afaict. fair enough, but it means that those who want to use PV calls/9pfs will not be able to do so with C89, right? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/x86: ensure copying to L1 guest in update_runstate_area()
>>> On 22.02.17 at 03:20, wrote: > On 02/22/17 09:28 +0800, Haozhong Zhang wrote: >> On 02/21/17 02:15 -0700, Jan Beulich wrote: >> > >>> On 21.02.17 at 03:11, wrote: > [..] >> > > + * >> > > + * Therefore, we clear the nested guest flag before >> > > __raw_copy_to_guest() >> > > + * and __copy_to_guest(), and restore the flag after all guest copy. >> > > + */ >> > > +if ( is_hvm_vcpu(v) && paging_mode_hap(v->domain) ) >> > > > I think it would be clearer to use nestedhvm_enabled() here. Indeed - that would eliminate all these open coding of assumption which may be valid at present, but not down the road. >> > And why is this HAP-specific? >> > >> >> IIUC, nested HVM relies on HAP. > > For nested SVM, I find the following check in hvmop_set_param(): > case HVM_PARAM_NESTEDHVM: > if ( cpu_has_svm && !paging_mode_hap(d) && a.value ) > rc = -EINVAL; > > I don't find the similar check for nested VMX here and in vvmx.c. > Though L1 HVM domain w/ nestedhvm=1 and hap=0 can boot up on Intel > machine (because of the lack of above check?), starting L2 guest does > crash L1 at the very beginning and L0 Xen reports the following debug > messages: > > (XEN) realmode.c:111:d18v9 Failed to emulate insn. > (XEN) Real-mode emulation failed: d18v9 Real @ f000:fff0 -> > (XEN) domain_crash called from realmode.c:157 > (XEN) Domain 18 (vcpu#9) crashed on cpu#29: > (XEN) [ Xen-4.9-unstable x86_64 debug=y Not tainted ] > (XEN) CPU:29 > (XEN) RIP:f000:[] > (XEN) RFLAGS: 0002 CONTEXT: hvm guest (d18v9) > (XEN) rax: rbx: rcx: > (XEN) rdx: 0f61 rsi: rdi: > (XEN) rbp: rsp: r8: > (XEN) r9: r10: r11: > (XEN) r12: r13: r14: > (XEN) r15: cr0: 0030 cr4: 2050 > (XEN) cr3: feffc000 cr2: > (XEN) ds: es: fs: gs: ss: cs: f000 Now that's of course quite odd: The instruction at that address ought to be a direct far branch, which I think the emulator is able to deal with. Which leaves the possibility of it fetching the wrong bytes (which sadly don't get shown above). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes
>>> On 22.02.17 at 08:16, wrote: > 3. C89 - Jan, we discussed that a bit for zero-sized arrays [2] > and empty structures [3]. So, then we came to a conclusion that > breakage is not acceptable, but now I see that you have changed > your mind? (Please correct me if I got it wrong). The reason I am > bringing this back to life is that sndif and displif protocols > use grefs[1] construct, while originally I was about to avoid that "1". > So, as now Stefano introduces *grant_ref_t ref[];* I would also > like to change sndif/displif to use the same. Do you think it can be > done this time? I don't think so, no. Please pay close attention to the reason why I think an exception is fine in the case here, but not there: Someone including ring.h without actively using the new macro will not see a compile failure. Someone including sndif.h, otoh, would afaict. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 06/10] x86/cpuid: Handle leaf 0x6 in guest_cpuid()
>>> On 21.02.17 at 18:40, wrote: > On 21/02/17 17:25, Jan Beulich wrote: > On 20.02.17 at 12:00, wrote: >>> The thermal/performance leaf was previously hidden from HVM guests, but > fully >>> visible to PV guests. Most of the leaf refers to MSR availability, and > there >>> is nothing an unprivileged PV guest can do with the information, so hide the >>> leaf entirely. >>> >>> The PV MSR handling logic as minimal support for some thermal/perf >>> operations >> ... has ... >> >>> from the hardware domain, so leak through the implemented subset of >>> features. >> Does it make sense to continue to special case PV hwdom here? > > Being able to play with these MSRs will be actively wrong for HVM > context. It is already fairly wrong for PV context, as nothing prevents > you being rescheduled across pcpus while in the middle of a read/write > cycle on the MSRs. So the MSRs in question are, afaics - MSR_IA32_MPERF, MSR_IA32_APERF, MSR_IA32_PERF_CTL (all of which are is_cpufreq_controller() dependent) - MSR_IA32_THERM_CONTROL, MSR_IA32_ENERGY_PERF_BIAS (both of which are is_pinned_vcpu() dependent) For the latter your argument doesn't apply. For the former, I've been wondering for a while whether we shouldn't do away with "cpufreq=dom0-kernel". >> Should there perhaps be at least a fixme note? > > One way or another, we have to invest some different mechanism of > providing real hardware details to the hardware domain which don't > collide with their vcpus. Hence the question whether to at least add a "fixme" note. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 04/10] x86/cpuid: Handle leaf 0x4 in guest_cpuid()
>>> On 21.02.17 at 18:35, wrote:
> On 21/02/17 17:16, Jan Beulich wrote:
> On 20.02.17 at 12:00, wrote:
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -163,6 +163,9 @@ static void recalculate_xstate(struct cpuid_policy *p)
>>> */
>>> static void recalculate_misc(struct cpuid_policy *p)
>>> {
>>> +/* Leaves with subleaf unions. */
>>> +p->basic.raw[0x4] = p->basic.raw[0x7] = p->basic.raw[0xd] = EMPTY_LEAF;
>> How come you play with leaves 7 and 0xd here?
>
> This particular piece of clobbering was something which has only just
> occurred to me now when implementing the leaf 4 union.
>
> Then again, there is no supported way of getting any values into those
> particular rows, or reading out of them, so I could just rely on no-one
> caring?
Well, if they start out as EMPTY_LEAF and there's no way to get
other values into them, why bother filling them here? The more
with a line that doesn't allow neatly extending should one more
such leaf need adding here. I'd say if you want to clobber the
values here just in case, merge the assignments above (in
numeric order) with the ones that are already there just below
(visible in the original patch context).
>>> @@ -244,6 +248,25 @@ static void __init calculate_raw_policy(void)
>>> cpuid_leaf(i, &p->basic.raw[i]);
>>> }
>>>
>>> +if ( p->basic.max_leaf >= 4 )
>>> +{
>>> +for ( i = 0; i < ARRAY_SIZE(p->cache.raw); ++i )
>>> +{
>>> +cpuid_count_leaf(4, i, &p->cache.raw[i]);
>>> +
>>> +if ( p->cache.subleaf[i].type == 0 )
>>> +break;
>>> +}
>>> +
>>> +/*
>>> + * The choice of CPUID_GUEST_NR_CACHE is arbitrary. It is expected
>>> + * that it will eventually need increasing for future hardware.
>>> + */
>>> +if ( i == ARRAY_SIZE(p->cache.raw) )
>>> +printk(XENLOG_WARNING
>>> + "CPUID: Insufficient Leaf 4 space for this hardware\n");
>>> +}
>> It probably doesn't hurt, but it's one off: There's no enough space
>> only when the next (i-th) doesn't report type 0.
>
> This bit of logic is slightly awkward. We read into p->cache.raw[i]
> before looking to see whether p->cache.subleaf[i].type is the end of the
> list. As such we always read one-past-the-end.
Sure. Issuing the message prematurely could of course be avoided
nevertheless, by reading sub-leaf i (regardless of whether i ==
CPUID_GUEST_NR_CACHE) into a local variable and checking type
there. But as said, it's not something I strictly ask for to be done,
as I can also see upsides of seeing this warning earlier than
absolutely needed.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 03/10] x86/cpuid: Handle leaf 0x1 in guest_cpuid()
>>> On 21.02.17 at 18:29, wrote: > On 21/02/17 17:20, Jan Beulich wrote: >> > The final 8 bits are the initial legacy APIC ID. For HVM guests, this was > overridden to vcpu_id * 2. The same logic is now applied to PV guests, so > guests don't observe a constant number on all vcpus via their emulated or > faulted view. They won't be the same everywhere, but every 128th CPU will share values. I'm therefore not sure it wouldn't be better to hand out zero or all ones here. >>> There is no case where 128 cpus work sensibly under Xen ATM. >> For HVM you mean. I'm sure I've seen > 128 vCPU PV guests >> (namely Dom0-s). > > You can physically create PV domains with up to 8192 vcpus. I tried > this once. > > The NMI watchdog (even set to 10s) is unforgiving of some the > for_each_vcpu() loops during domain destruction. > > I can also still create workloads in a 64vcpu HVM guest which will cause > a 5 second watchdog timeout, which is why XenServers upper supported > vcpu limit is still 32. Which does not contradict what I've said: I didn't claim 8k-vCPU guests would work well, but I'm pretty convinced ones in the range 128...512 have reasonable chances of working. And we both know the situation sadly is worse for HVM ones. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes
Hi, Stefano, Jan! 1. Stefano, are you still NOT considering adding functionality to avoid memory copying? We discussed this a little bit here [1]. 2. Will you also provide macros/inlines for fixed sized packets? So, others do not reinvent the wheel again on top of your code. 3. C89 - Jan, we discussed that a bit for zero-sized arrays [2] and empty structures [3]. So, then we came to a conclusion that breakage is not acceptable, but now I see that you have changed your mind? (Please correct me if I got it wrong). The reason I am bringing this back to life is that sndif and displif protocols use grefs[1] construct, while originally I was about to avoid that "1". So, as now Stefano introduces *grant_ref_t ref[];* I would also like to change sndif/displif to use the same. Do you think it can be done this time? Thank you, Oleksandr [1] https://marc.info/?l=xen-devel&m=148356651811001&w=2 [2] https://marc.info/?l=xen-devel&m=148006553214656&w=2 [3] https://marc.info/?l=xen-devel&m=148000448701946&w=2 On 02/22/2017 01:25 AM, Stefano Stabellini wrote: This patch introduces macros, structs and functions to handle rings in the format described by docs/misc/pvcalls.markdown and docs/misc/9pfs.markdown. The index page (struct __name##_data_intf) contains the indexes and the grant refs to setup two rings. Indexes page +--+ |@0 $NAME_data_intf: | |@76: ring_order = 1 | |@80: ref[0]+ | |@84: ref[1]+ | | | | | | | +--+ | v (data ring) +---+---+ | @0->4098: in | | ref[0] | |---| | @4099->8196: out | | ref[1] | +---+ $NAME_read_packet and $NAME_write_packet are provided to read or write any data struct from/to the ring. In pvcalls, they are unused. In xen 9pfs, they are used to read or write the 9pfs header. In other protocols they could be used to read/write the whole request structure. See docs/misc/9pfs.markdown:Ring Usage to learn how to check how much data is on the ring, and how to handle notifications. There is a ring_size parameter to most functions so that protocols using these macros don't have to have a statically defined ring order at build time. In pvcalls for example, each new ring could have a different order. These macros don't help you share the indexes page or the event channels needed for notifications. You can do that with other out of band mechanisms, such as xenstore or another ring. It is not possible to use a macro to define another macro with a variable name. For this reason, this patch introduces static inline functions instead, that are not C89 compliant. Additionally, the macro defines a struct with a variable sized array, which is also not C89 compliant. Signed-off-by: Stefano Stabellini CC: konrad.w...@oracle.com CC: andr2...@gmail.com CC: oleksandr_andrushche...@epam.com CC: andrii.ani...@gmail.com CC: vlad.babc...@gmail.com CC: al1...@gmail.com CC: jocula...@gmail.com --- Changes in v3: - mention C89 compliance breakages - constify parameters - use unsigned chars for buffers - add two macros, one doesn't define the struct Changes in v2: - fix typo - remove leading underscores from names - use UL - do not parenthesize parameters - code readability improvements Give a look at the following branch to see how they are used with pvcalls and xen-9pfs (the drivers are still work in progress): git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 9pfs-async-v6 --- --- xen/include/public/io/ring.h | 120 +++ 1 file changed, 120 insertions(+) diff --git a/xen/include/public/io/ring.h b/xen/include/public/io/ring.h index 801c0da..4d36f06 100644 --- a/xen/include/public/io/ring.h +++ b/xen/include/public/io/ring.h @@ -313,6 +313,126 @@ typedef struct __name##_back_ring __name##_back_ring_t (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r); \ } while (0) + +/* + * DEFINE_XEN_FLEX_RING_AND_INTF defines two monodirectional rings and + * functions to check if there is data on the ring, and to read and + * write to them. + * + * DEFINE_XEN_FLEX_RING is similar to DEFINE_XEN_FLEX_RING_AND_INTF, but + * does not define the indexes page. As different protocols can have + * extensions to the basic format, this macro allow them to define their + * own struct. + * + * XEN_FLEX_RING_SIZE + * Convenience macro to calculate the size of one of the two rings + * from the overall order. + * + * $NAME_mask + * Function to apply the size mask to an index, to reduce the index + * within the range [0-
Re: [Xen-devel] [PATCH 02/10] x86/gen-cpuid: Clarify the intended meaning of AVX wrt feature dependencies
>>> On 21.02.17 at 18:42, wrote:
> On 21/02/17 17:17, Jan Beulich wrote:
> On 21.02.17 at 18:12, wrote:
>>> Which particular feature groups? I could extend that text to say
>>>
>>> "VEX/XOP-encoded GPR instructions, such as those from the BMI{1,2} and
>>> $X sets..."
>> TBM and LWP.
>
> Ok. Final text reads:
>
> # AVX is not taken to mean support for the VEX prefix itself (nor XOP
> # for the XOP prefix). VEX/XOP-encoded GPR instructions, such as
> # those from the BMI{1,2}, TBM and LWP sets function fine in the
> # absence of any enabled xstate.
Thanks, looks good.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 07/28] ARM: GICv3 ITS: introduce device mapping
Hi Andre,
On Tue, Jan 31, 2017 at 12:01 AM, Andre Przywara wrote:
> The ITS uses device IDs to map LPIs to a device. Dom0 will later use
> those IDs, which we directly pass on to the host.
> For this we have to map each device that Dom0 may request to a host
> ITS device with the same identifier.
> Allocate the respective memory and enter each device into an rbtree to
> later be able to iterate over it or to easily teardown guests.
>
> Signed-off-by: Andre Przywara
> ---
> xen/arch/arm/gic-v3-its.c| 188
> ++-
> xen/arch/arm/vgic-v3.c | 3 +
> xen/include/asm-arm/domain.h | 3 +
> xen/include/asm-arm/gic_v3_its.h | 28 ++
> 4 files changed, 221 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index 6578e8a..4a3a394 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -21,8 +21,10 @@
> #include
> #include
> #include
> -#include
> +#include
> +#include
> #include
> +#include
> #include
> #include
> #include
> @@ -94,6 +96,21 @@ static int its_send_cmd_mapc(struct host_its *its, int
> collection_id, int cpu)
> return its_send_command(its, cmd);
> }
>
> +static int its_send_cmd_mapd(struct host_its *its, uint32_t deviceid,
> + int size, uint64_t itt_addr, bool valid)
> +{
> +uint64_t cmd[4];
> +
> +cmd[0] = GITS_CMD_MAPD | ((uint64_t)deviceid << 32);
> +cmd[1] = size & GENMASK(4, 0);
> +cmd[2] = itt_addr & GENMASK(51, 8);
> +if ( valid )
> +cmd[2] |= GITS_VALID_BIT;
> +cmd[3] = 0x00;
> +
> +return its_send_command(its, cmd);
> +}
> +
> /* Set up the (1:1) collection mapping for the given host CPU. */
> int gicv3_its_setup_collection(int cpu)
> {
> @@ -293,6 +310,7 @@ int gicv3_its_init(struct host_its *hw_its)
> reg = readq_relaxed(hw_its->its_base + GITS_TYPER);
> if ( reg & GITS_TYPER_PTA )
> hw_its->flags |= HOST_ITS_USES_PTA;
> +hw_its->itte_size = GITS_TYPER_ITT_SIZE(reg);
>
> for ( i = 0; i < GITS_BASER_NR_REGS; i++ )
> {
> @@ -339,6 +357,173 @@ int gicv3_its_init(struct host_its *hw_its)
> return 0;
> }
>
> +static void remove_mapped_guest_device(struct its_devices *dev)
> +{
> +if ( dev->hw_its )
> +its_send_cmd_mapd(dev->hw_its, dev->host_devid, 0, 0, false);
> +
> +xfree(dev->itt_addr);
> +xfree(dev);
> +}
> +
> +int gicv3_its_map_guest_device(struct domain *d, int host_devid,
> + int guest_devid, int bits, bool valid)
> +{
> +void *itt_addr = NULL;
> +struct its_devices *dev, *temp;
> +struct rb_node **new = &d->arch.vgic.its_devices.rb_node, *parent = NULL;
> +struct host_its *hw_its;
> +int ret;
> +
> +/* check for already existing mappings */
> +spin_lock(&d->arch.vgic.its_devices_lock);
> +while (*new)
> +{
> +temp = rb_entry(*new, struct its_devices, rbnode);
> +
> +if ( temp->guest_devid == guest_devid )
> +{
> +if ( !valid )
> +rb_erase(&temp->rbnode, &d->arch.vgic.its_devices);
> +
> +spin_unlock(&d->arch.vgic.its_devices_lock);
> +
> +if ( valid )
> +return -EBUSY;
> +
> +remove_mapped_guest_device(temp);
> +
> +return 0;
> +}
> +
> +if ( guest_devid < temp->guest_devid )
> +new = &((*new)->rb_right);
Shouldn't be rb_left here?
> +else
> +new = &((*new)->rb_left);
Shouldn't be rb_right here?
> +}
I see duplicate code in find and inserting node into rb_tree.
> +
> +if ( !valid )
> +{
> +ret = -ENOENT;
> +goto out_unlock;
> +}
> +
> +/*
> + * TODO: Work out the correct hardware ITS to use here.
> + * Maybe a per-platform function: devid -> ITS?
> + * Or parsing the DT to find the msi_parent?
> + * Or get Dom0 to give us this information?
> + * For now just use the first ITS.
> + */
> +hw_its = list_first_entry(&host_its_list, struct host_its, entry);
> +
> +ret = -ENOMEM;
> +
> +itt_addr = _xmalloc(BIT(bits) * hw_its->itte_size, 256);
> +if ( !itt_addr )
> +goto out_unlock;
> +
> +dev = xmalloc(struct its_devices);
> +if ( !dev )
> +{
> +xfree(itt_addr);
> +goto out_unlock;
> +}
> +
> +ret = its_send_cmd_mapd(hw_its, host_devid, bits - 1,
> +virt_to_maddr(itt_addr), true);
> +if ( ret )
> +{
> +xfree(itt_addr);
> +xfree(dev);
> +goto out_unlock;
> +}
> +
> +dev->itt_addr = itt_addr;
> +dev->hw_its = hw_its;
> +dev->guest_devid = guest_devid;
> +dev->host_devid = host_devid;
> +dev->eventids = BIT(bits);
> +
> +rb_link_node(&dev->rbnode, parent, new);
parent is not updated before inserting. So whole tree is not
managed properly.
> +rb_insert_color(&dev->rbn
[Xen-devel] [qemu-upstream-4.6-testing test] 105958: regressions - FAIL
flight 105958 qemu-upstream-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105958/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail REGR. vs. 105693 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105693 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105693 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105693 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105693 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 105693 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: qemuu722ce03b32f37ef5af09105727b574339326d354 baseline version: qemuu15c0f1500fc078b6411d2c86842cb2f3fd7393c0 Last test of basis 105693 2017-02-10 10:43:47 Z 11 days Testing same since 105958 2017-02-21 19:50:46 Z0 days1 attempts People who touched revisions under test: Bruce Rogers Gerd Hoffmann 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-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm
Re: [Xen-devel] kpartx for raisin hvm tests
On 2017-02-21 23:10, Stefano Stabellini wrote: On Tue, 21 Feb 2017, Géza Gémes wrote: Hi, I've tried to run the raisin test suite, while pv tests pass the hvm tests fail. I've identified a number of problems, starting with two small disk size to formating the whole disk and then being unable to install grub to the boot sector. I've trace down these problems into the incorrect invocation of the _create_loop_device function in scripts/lopartsetup. My question: Will it be acceptable if I would replace this part of the code with a kpartx call? Or introducing kpartx is a too big change in the list of dependencies? I understand that kpartx makes things much easier, but before introducing it as a dependency, I would like to understand this problem a bit better. Why is _create_loop_device invoked incorrectly? Is it index or offset that is calculate incorrectly? Hi Stefano, In scripts/lopartsetup:56 unit="`fdisk -lu $filename 2>/dev/null | grep -e "^Units = " | cut -d " " -f 9`" . Using ubuntu 16.04 (fdisk coming from util-linux-2.27.1-6ubuntu3.2) this yields to an empty variable, as: $sudo fdisk -lu /tmp/tmp.x9UN6uxaG2/busybox-vm-disk 2>/dev/null Disk /tmp/tmp.x9UN6uxaG2/busybox-vm-disk: 60 MiB, 62914560 bytes, 122880 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Because of this both unit and offset are wrong ( offset=`echo $i | tr -s " " | cut -d " " -f 2`, where i=fdisk -lu $filename 2>/dev/null | grep -e "^$filename") As I think that different versions of fdisk will produce different results, we either introduce an additional logic for the fdisk version, either change this part completely. Cheers, Geza ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 4/4] KVM: VMX: Simplify segment_base
* Paolo Bonzini wrote: > > Paolo, how stable, non-rebasing are the KVM tree commits? > > Whatever ends in linux-next is stable. I have a separate rebasing branch, > but it's not part of linux-next by design. Ok, that's nice! > > Or should we keep Andy's KVM patches together with the GDT patches? Either > > workflow works for me - it's your call as these are predominantly KVM > > changes. > > I'll delay my pull request to Linus a couple days so that I can test Andy's 6 > patches. Then you can just base your branch on Linus's tree. Fantastic, thank you! Ingo ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline baseline-only test] 68596: regressions - trouble: blocked/broken/fail/pass
This run is configured for baseline tests only. flight 68596 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68596/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pygrub 13 guest-saverestore fail REGR. vs. 68584 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 68584 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 68584 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 68584 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68584 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-installfail like 68584 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 2 hosts-allocate broken never pass build-arm64-pvops 2 hosts-allocate broken never pass build-arm64-xsm 2 hosts-allocate broken never pass build-arm64 3 capture-logs broken never pass build-arm64-pvops 3 capture-logs broken never pass build-arm64-xsm 3 capture-logs broken never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: qemuu56f9e46b841c7be478ca038d8d4085d776ab4b0d baseline version: qemuud514cfd763b271b4e97a9fc6adaabc8fd50084ab Last test of basis68584 2017-02-20 19:16:37 Z1 days Testing same since68596 2017-02-21 20:48:58 Z0 days1 attempts People who touched revisions under test: Anatoli Huseu1 Fabian Lesniak Frediano Ziglio Gerd Hoffmann Marc-André Lureau Markus Armbruster Peter Maydell Thomas Huth jobs: build-amd64-xsm pass build-a
[Xen-devel] [ovmf baseline-only test] 68597: all pass
This run is configured for baseline tests only. flight 68597 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68597/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 85520606ad459ba7d825c7ea5f225cffa1dbe95b baseline version: ovmf 5af4388433e13ffeda980116d92f4230c79e483d Last test of basis68588 2017-02-21 12:17:08 Z0 days Testing same since68597 2017-02-21 21:47:29 Z0 days1 attempts People who touched revisions under test: Dandan Bi Hao Wu Jiewen Yao Ruiyu Ni Yao Jiewen 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.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. (No revision log; it would be 368 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Added as CC - [#29506] [Xen-announce] Xen Security Advisory 209 (CVE-2017-2620) - cirrus_bitblt_cputovideo does not check if memory region is safe
Xen.org security team submitted a new ticket to Firelay/Proteon Support Portal and requested that we copy you Ticket Description: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2017-2620 / XSA-209 version 3 cirrus_bitblt_cputovideo does not check if memory region is safe UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = In CIRRUS_BLTMODE_MEMSYSSRC mode the bitblit copy routine cirrus_bitblt_cputovideo fails to check wethehr the specified memory region is safe. IMPACT == A malicious guest administrator can cause an out of bounds memory write, very likely exploitable as a privilege escalation. VULNERABLE SYSTEMS == Versions of qemu shipped with all Xen versions are vulnerable. Xen systems running on x86 with HVM guests, with the qemu process running in dom0 are vulnerable. Only guests provided with the "cirrus" emulated video card can exploit the vulnerability. The non-default "stdvga" emulated video card is not vulnerable. (With xl the emulated video card is controlled by the "stdvga=" and "vga=" domain configuration options.) ARM systems are not vulnerable. Systems using only PV guests are not vulnerable. For VMs whose qemu process is running in a stub domain, a successful attacker will only gain the privileges of that stubdom, which should be only over the guest itself. Both upstream-based versions of qemu (device_model_version="qemu-xen") and `traditional' qemu (device_model_version="qemu-xen-traditional") are vulnerable. MITIGATION == Running only PV guests will avoid the issue. Running HVM guests with the device model in a stubdomain will mitigate the issue. Changing the video card emulation to stdvga (stdvga=1, vga="stdvga", in the xl domain configuration) will avoid the vulnerability. CREDITS === This issue was discovered by Gerd Hoffmann of Red Hat. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa209-qemuu.patch qemu-xen, qemu upstream (no backport yet)qemu-xen-traditional $ sha256sum xsa209* 167af9ed7163fa7cf4abb52f865290ced3163c7684151bdc1324eb5e534faf13 xsa209-qemut.patch 297578aa43c3e6b21333f1b859fd1d3e68e77b3cadbadd20cfeca8426df3 xsa209-qemuu.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. However, deployment of the "stdvga" mitigation (changing the video card emulation to stdvga) is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because this produces a guest-visible change which will indicate which component contains the vulnerability. Additionally, distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYrBl3AAoJEIP+FMlX6CvZ6LMIALETwnX9w8SifkvuYY3jotwp nQWY8ztJkMnai9X10RN6SeVf2dCpXLhATPuPGORgRiZJEuBaGHEsHa00i63FQBSL PaOAgzN1GY+u16Ygv2e3vPcN8mO55A6zcFErF2oLsrfdNsG4pJTwn7bMEjZiqSyG R9xIC6KiA1nojsZO+ynmRvHxFP6epySRayO0PZAGS75LdmEKVxClE3dAeMW77WNv dAs3Qi14hB5BmdryK5f1STk8r2b3UsN1pbvao8odiEWFaB9tPo273gj5RdfnEV3t EzTvH37Q3C4YFoTFx8p6fY5ejHNh4AeSyi9yE7lWtKhDZw56UhdfMmYIgDaKpig= =RBpg -END PGP SIGNATURE- ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-4.8-testing test] 105957: tolerable FAIL - PUSHED
flight 105957 qemu-upstream-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105957/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-xsm 5 xen-buildfail never pass build-arm64-pvops 5 kernel-build fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail never pass version targeted for testing: qemuu145e78b40a3daed1097c803f31538bafe32400d9 baseline version: qemuu46e1db013347a3356ac05b83c0243313d74d2193 Last test of basis 105695 2017-02-10 11:31:22 Z 11 days Testing same since 105957 2017-02-21 19:13:45 Z0 days1 attempts People who touched revisions under test: Bruce Rogers Gerd Hoffmann jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 fail build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt blocked build-armhf-libvirt pass build-i386-libvirt p
Re: [Xen-devel] [PATCH v8 0/7] VMX: Properly handle pi descriptor and per-cpu blocking list
Hi, everyone. Really sorry for digging out this thread. Because feng has left Intel, I will take over this work, address some problems in his v8 patch set and send out a v9 verson later such that VT-d PI can work properly on Xen. Thanks, Chao On Fri, Nov 18, 2016 at 09:57:17AM +0800, Wu, Feng wrote: >The current VT-d PI related code may operate incorrectly in the >following scenarios: >1. When the last assigned device is dettached from the domain, all >the PI related hooks are removed then, however, the vCPU can be >blocked, switched to another pCPU, etc, all without the aware of >PI. After the next time we attach another device to the domain, >which makes the PI realted hooks avaliable again, the status >of the pi descriptor is not true. Beside that, the blocking vcpu >may still remain in the per-cpu blocking in this case. Patch [1/7] >and [2/7] handle this. > >2. [4/7] unify the code path of PI mode update and remapped mode update > >2. When IRTE is in posted mode, we don't need to set the irq >affinity for it, since the destination of these interrupts is >vCPU and the vCPU affinity is set during vCPU scheduling. Patch >[5/7] handles this. > >4. [6/7] is a cleanup patch > >5. When a pCPU is unplugged, and there might be vCPUs on its >list. Since the pCPU is offline, those vCPUs might not be woken >up again. [7/7] addresses it. > > >Feng Wu (7): > VMX: Permanently assign PI hook vmx_pi_switch_to() > VMX: Properly handle pi when all the assigned devices are removed > VMX: Make sure PI is in proper state before install the hooks > VT-d: Use one function to update both remapped and posted IRTE > VT-d: No need to set irq affinity for posted format IRTE > VT-d: Some cleanups > VMX: Fixup PI descriptor when cpu is offline > > xen/arch/x86/hvm/vmx/vmcs.c| 14 +-- > xen/arch/x86/hvm/vmx/vmx.c | 133 ++- > xen/drivers/passthrough/pci.c | 14 +++ > xen/drivers/passthrough/vtd/intremap.c | 193 +++-- > xen/include/asm-x86/hvm/vmx/vmx.h | 3 + > 5 files changed, 240 insertions(+), 117 deletions(-) > >-- >2.1.0 > > >___ >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] xen/arm: introduce vwfi parameter
On Tue, Feb 21, 2017 at 07:20:29PM +, Julien Grall wrote: > > > On 21/02/2017 18:30, Stefano Stabellini wrote: > >On Tue, 21 Feb 2017, Julien Grall wrote: > >>Hi Stefano, > >> > >>On 21/02/17 17:49, Stefano Stabellini wrote: > >>>On Tue, 21 Feb 2017, Dario Faggioli wrote: > On Tue, 2017-02-21 at 13:46 +, George Dunlap wrote: > Oh, actually, if --which I only now realize may be what you are > referring to, since you're talking about "guest burning its credits"-- > you let the vCPU put the pCPU to sleep *but*, when it wakes up (or when > the scheduler runs again for whatever reason), you charge to it for all > the time the the pCPU was actually idle/sleeping, well, that may > actually not break scheduling, or cause disruption to the service of > other vCPUs But indeed I'd consider it rather counter intuitive a > behavior. > >>> > >>>How can this be safe? There could be no interrupts programmed to wake up > >>>the pcpu at all. In fact, I don't think today there would be any, unless > >>>we set one up in Xen for the specific purpose of interrupting the pcpu > >>>sleep. > >>> > >>>I don't know the inner working of the scheduler, but does it always send > >>>an interrupt to other pcpu to schedule something? > >> > >>You still seem to assume that WFI/WFE is the only way to get a vCPU > >>unscheduled. If that was the case it would be utterly wrong because you > >>cannot > >>expect a guest to use them. > >> > >>> > >>>What if there are 2 vcpu pinned to the same pcpu? This cannot be fair. > >> > >>Why wouldn't it be fair? This is the same situation as a guest vCPU not > >>using > >>WFI/WFE. > > > >I read your suggestion as trapping WFI in Xen, then, depending on > >settings, executing WFI in the Xen trap handler to idle the pcpu. That > >doesn't work. But I take you suggested not trapping wfi (remove > >HCR_TWI), executing the instruction in guest context. That is what we > >used to do in the early days (before a780f750). It should be safe and > >possibly even quick. I'll rerun the numbers and let you know. > > My first suggestion was to emulate WFI in Xen, which I agree is not safe :). > > I think not trapping WFI will have the best performance but may impact the > credit of the vCPU as mentioned by Dario and George. I agree, wfi in guest context or at least with everything prepared to return to the current guest would be great. An option to enable this would work fine for our use-cases. Or if we could at runtime detect that it's the best approach given scheduling (i.e exclusive vCPU/pCPU pinning) even better. Cheers, Edgar ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document
On Mon, Feb 13, 2017 at 03:35:19PM +, Julien Grall wrote:
> On 02/02/17 15:33, Edgar E. Iglesias wrote:
> >On Wed, Feb 01, 2017 at 07:04:43PM +, Julien Grall wrote:
> >>On 31/01/2017 19:06, Edgar E. Iglesias wrote:
> >>>On Tue, Jan 31, 2017 at 05:09:53PM +, Julien Grall wrote:
> >>Thank you for the documentation. I am trying to understand if we could move
> >>initialization in Xen as suggested by Stefano. I looked at the driver in
> >>Linux and the code looks simple not many dependencies. However, I was not
> >>able to find where the Gigabit Transceivers are configured. Do you have any
> >>link to the code for that?
> >
> >Hi Julien,
>
> Hi Edgar,
Hi Julien,
Sorry for the late reply..
>
> >
> >I suspect that this setup has previously been done by the initial bootloader
> >auto-generated from design configuration tools.
> >
> >Now, this is moving into Linux.
>
> Do you know why they decide to move the code in Linux? What would be the
> problem to let the bootloader configuring the GT?
No, I'm not sure why this approach was not used. The only thing I can think of
is a runtime configuration approach.
>
> >There's a specific driver that does that but AFAICS, it has not been
> >upstreamed yet.
> >You can see it here:
> >https://github.com/Xilinx/linux-xlnx/blob/master/drivers/phy/phy-zynqmp.c
> >
> >DTS nodes that need a PHY can then just refer to it, here's an example from
> >SATA:
> >&sata {
> >phy-names = "sata-phy";
> >phys = <&lane3 PHY_TYPE_SATA 1 3 15000>;
> >};
> >
> >I'll see if I can find working examples for PCIe on the ZCU102. Then I'll
> >share
> >DTS, Kernel etc.
>
> I've found a device tree on the github from the ZCU102: zynqmp-zcu102.dts,
> it looks like there is no use of PHY for the pcie so far.
>
> Lets imagine in the future, pcie will use the PHY. If we decide to
> initialize the hostbridge in Xen, we would also have to pull the PHY code in
> the hypervisor. Leaving aside the problem to pull more code in Xen, this is
> not nice because the PHY is used by different components (e.g SATA, USB). So
> Xen and DOM0 would have to share the PHY.
>
> For Xen POV, the best solution would be the bootloader initializing the PHY
> because starting Xen. So we can keep all the hostbridge (initialization +
> access) in Xen.
>
> If it is not possible, then I would prefer to see the hostbridge
> initialization in DOM0.
Yes, I agree that the GT setup in the bootloader is very attractive.
I don't think hte setup sequence is complicated, we can perhaps even do it
on the commandline in u-boot or xsdb. I'll have to check.
>
> >
> >If you are looking for a platform to get started, an option could be if I
> >get you a build of
> >our QEMU that includes models for the PCIe controller, MSI and SMMU
> >connections.
> >These models are friendly wrt. PHY configs and initialization sequences, it
> >will
> >accept pretty much any sequence and still work. This would allow you to
> >focus on
> >architectural issues rather than exact details of init sequences (which we
> >can
> >deal with later).
>
> From my understanding the problem is where the hostbridge should be
> initialized. In an ideal world, I think this is the goal of the bootloader.
> If it is not possible then depending on the complexity, the initialization
> would have to be done either in Xen or DOM0.
>
> I guess this could be decided on case by case basis. I will suggest
> different possibility in the design document.
>
> [...]
>
> >>
> >>From a design point of view, it would make more sense to have the MSI
> >>controller driver in Xen as the hostbridge emulation for guest will also
> >>live there.
> >>
> >>So if we receive MSI in Xen, we need to figure out a way for DOM0 and guest
> >>to receive MSI. The same way would be the best, and I guess non-PV if
> >>possible. I know you are looking to boot unmodified OS in a VM. This would
> >>mean we need to emulate the MSI controller and potentially xilinx PCI
> >>controller. How much are you willing to modify the OS?
> >
> >Today, we have not yet implemented PCIe drivers for our baremetal SDK. So
> >things are very open and we could design with pretty much anything in mind.
> >
> >Yes, we could perhaps include a very small model with most registers dummied.
> >Implementing the MSI read FIFO would allow us to:
> >
> >1. Inject the MSI doorbell SPI into guests. The guest will then see the same
> > IRQ as on real HW.
> >
> >2. Guest reads host-controller registers (MSI FIFO) to get the signaled MSI.
>
> The Xilinx PCIe hostbridge is not the only hostbridge having MSI controller
> embedded. So I would like to see a generic solution if possible. This would
> avoid to increase the code required for emulation in Xen.
>
> My concern with a FIFO is it will require an upper bound to avoid using to
> much memory in Xen. What if the FIFO is full? Will you drop MSI?
The FIFO I'm refering to is a FIFO in the MSI controller itself.
I agree that this wouldn't be g
[Xen-devel] [qemu-upstream-unstable test] 105955: tolerable FAIL - PUSHED
flight 105955 qemu-upstream-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/105955/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105894 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105894 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105894 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 105894 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 5 xen-buildfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass build-arm64 5 xen-buildfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass build-arm64-pvops 5 kernel-build fail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass version targeted for testing: qemuu57e8fbb2f702001a18bd81e9fe31b26d94247ac9 baseline version: qemuu08c008de9c7d3ac71f71c87cc04a47819ca228dc Last test of basis 105894 2017-02-18 02:23:38 Z4 days Testing same since 105955 2017-02-21 19:13:25 Z0 days1 attempts People who touched revisions under test: Gerd Hoffmann jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 fail build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt blocked build-armhf
[Xen-devel] [qemu-upstream-4.7-testing test] 105956: regressions - FAIL
flight 105956 qemu-upstream-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105956/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 guest-stop/l1/l2 fail REGR. vs. 105732 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 105732 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105732 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105732 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105732 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 105732 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 5 xen-buildfail never pass build-arm64 5 xen-buildfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass build-arm64-pvops 5 kernel-build fail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: qemuu15268f91fbe75b38a851c458aef74e693d646ea5 baseline version: qemuu7eaaf4ba68fab40f1945d761438bdaa44fbf37d7 Last test of basis 105732 2017-02-11 14:15:04 Z 10 days Testing same since 105956 2017-02-21 19:13:25 Z0 days1 attempts People who touched revisions under test: Bruce Rogers Gerd Hoffmann jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 fail build-armhf
Re: [Xen-devel] [PATCH] xen/x86: ensure copying to L1 guest in update_runstate_area()
> From: Zhang, Haozhong > Sent: Wednesday, February 22, 2017 10:21 AM > > > > > > > > And why is this HAP-specific? > > > > > > > IIUC, nested HVM relies on HAP. > > For nested SVM, I find the following check in hvmop_set_param(): > case HVM_PARAM_NESTEDHVM: > if ( cpu_has_svm && !paging_mode_hap(d) && a.value ) > rc = -EINVAL; > > I don't find the similar check for nested VMX here and in vvmx.c. > Though L1 HVM domain w/ nestedhvm=1 and hap=0 can boot up on Intel > machine (because of the lack of above check?), starting L2 guest does > crash L1 at the very beginning and L0 Xen reports the following debug > messages: > > (XEN) realmode.c:111:d18v9 Failed to emulate insn. > (XEN) Real-mode emulation failed: d18v9 Real @ f000:fff0 -> > (XEN) domain_crash called from realmode.c:157 > (XEN) Domain 18 (vcpu#9) crashed on cpu#29: > (XEN) [ Xen-4.9-unstable x86_64 debug=y Not tainted ] > (XEN) CPU:29 > (XEN) RIP:f000:[] > (XEN) RFLAGS: 0002 CONTEXT: hvm guest (d18v9) > (XEN) rax: rbx: rcx: > (XEN) rdx: 0f61 rsi: rdi: > (XEN) rbp: rsp: r8: > (XEN) r9: r10: r11: > (XEN) r12: r13: r14: > (XEN) r15: cr0: 0030 cr4: 2050 > (XEN) cr3: feffc000 cr2: > (XEN) ds: es: fs: gs: ss: cs: f000 > > I haven't dug into this problem, but I suspect there would be other > bugs when using nested VMX w/o HAP. Maybe we should add a similar check in > hvmop_set_param() for nested VMX as well. > > Kevin, any comments? > I don't recall the initial version of vvmx support - there is a possibility of not supporting HAP at that time which was introduced later. It's probably the reason why we don't limit it to HAP=1. But I'm OK to add similar check now - given HAP=0 is broken and less efficient than HAP=1 in nested situation. Thanks Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/3] x86/vpmu: Add get/put_vpmu() and VPMU_AVAILABLE
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: Tuesday, February 21, 2017 10:10 PM
>
> On 02/21/2017 03:09 AM, Tian, Kevin wrote:
> >> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> >> Sent: Saturday, February 18, 2017 1:40 AM
> >>
> >> vpmu_enabled() (used by hvm/pv_cpuid() to properly report 0xa leaf
> >> for Intel processors) is based on the value of VPMU_CONTEXT_ALLOCATED
> >> bit. This is problematic:
> >> * For HVM guests VPMU context is allocated lazily, during the first
> >> access to VPMU MSRs. Since the leaf is typically queried before guest
> >> attempts to read or write the MSRs it is likely that CPUID will report
> >> no PMU support
> >> * For PV guests the context is allocated eagerly but only in responce to
> >> guest's XENPMU_init hypercall. There is a chance that the guest will
> >> try to read CPUID before making this hypercall.
> >>
> >> This patch introduces VPMU_AVAILABLE flag which is set (subject to
> >> vpmu_mode
> >> constraints) during VCPU initialization for both PV and HVM guests. Since
> >> this flag is expected to be managed together with vpmu_count,
> >> get/put_vpmu()
> >> are added to simplify code.
> >>
> >> vpmu_enabled() (renamed to vpmu_available()) can now use this new flag.
> >>
> >> (As a side affect this patch also fixes a race in pvpmu_init() where we
> >> increment vcpu_count in vpmu_initialise() after checking vpmu_mode)
> >>
> >> Signed-off-by: Boris Ostrovsky
> >> ---
> >> v2:
> >> * Rename VPMU_ENABLED to VPMU_AVAILABLE (and vpmu_enabled() to
> >> vpmu_available()
> >> * Check VPMU_AVAILABLE flag in put_vpmu() under lock
> >>
> >> xen/arch/x86/cpu/vpmu.c| 111
> >> ++---
> >> xen/arch/x86/cpuid.c | 8 ++--
> >> xen/arch/x86/domain.c | 5 ++
> >> xen/arch/x86/hvm/svm/svm.c | 5 --
> >> xen/arch/x86/hvm/vmx/vmx.c | 5 --
> >> xen/include/asm-x86/vpmu.h | 6 ++-
> >> 6 files changed, 88 insertions(+), 52 deletions(-)
> >>
> >> diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
> >> index 35a9403..b30769d 100644
> >> --- a/xen/arch/x86/cpu/vpmu.c
> >> +++ b/xen/arch/x86/cpu/vpmu.c
> >> @@ -456,32 +456,21 @@ int vpmu_load(struct vcpu *v, bool_t from_guest)
> >> return 0;
> >> }
> >>
> >> -void vpmu_initialise(struct vcpu *v)
> >> +static int vpmu_arch_initialise(struct vcpu *v)
> >> {
> >> struct vpmu_struct *vpmu = vcpu_vpmu(v);
> >> uint8_t vendor = current_cpu_data.x86_vendor;
> >> int ret;
> >> -bool_t is_priv_vpmu = is_hardware_domain(v->domain);
> >>
> >> BUILD_BUG_ON(sizeof(struct xen_pmu_intel_ctxt) > XENPMU_CTXT_PAD_SZ);
> >> BUILD_BUG_ON(sizeof(struct xen_pmu_amd_ctxt) > XENPMU_CTXT_PAD_SZ);
> >> BUILD_BUG_ON(sizeof(struct xen_pmu_regs) > XENPMU_REGS_PAD_SZ);
> >> BUILD_BUG_ON(sizeof(struct compat_pmu_regs) > XENPMU_REGS_PAD_SZ);
> >>
> >> -ASSERT(!vpmu->flags && !vpmu->context);
> >> +ASSERT(!(vpmu->flags & ~VPMU_AVAILABLE) && !vpmu->context);
> >>
> >> -if ( !is_priv_vpmu )
> >> -{
> >> -/*
> >> - * Count active VPMUs so that we won't try to change vpmu_mode
> >> while
> >> - * they are in use.
> >> - * vpmu_mode can be safely updated while dom0's VPMUs are active
> >> and
> >> - * so we don't need to include it in the count.
> >> - */
> >> -spin_lock(&vpmu_lock);
> >> -vpmu_count++;
> >> -spin_unlock(&vpmu_lock);
> >> -}
> >> +if ( !vpmu_available(v) )
> >> +return 0;
> >>
> >> switch ( vendor )
> >> {
> >> @@ -501,7 +490,7 @@ void vpmu_initialise(struct vcpu *v)
> >> opt_vpmu_enabled = 0;
> >> vpmu_mode = XENPMU_MODE_OFF;
> >> }
> >> -return; /* Don't bother restoring vpmu_count, VPMU is off forever
> >> */
> >> +return -EINVAL;
> >> }
> >>
> >> vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
> >> @@ -509,15 +498,63 @@ void vpmu_initialise(struct vcpu *v)
> >> if ( ret )
> >> printk(XENLOG_G_WARNING "VPMU: Initialization failed for %pv\n",
> >> v);
> >>
> >> -/* Intel needs to initialize VPMU ops even if VPMU is not in use */
> >> -if ( !is_priv_vpmu &&
> >> - (ret || (vpmu_mode == XENPMU_MODE_OFF) ||
> >> - (vpmu_mode == XENPMU_MODE_ALL)) )
> >> +return ret;
> >> +}
> >> +
> >> +static void get_vpmu(struct vcpu *v)
> >> +{
> >> +spin_lock(&vpmu_lock);
> >> +
> >> +/*
> >> + * Count active VPMUs so that we won't try to change vpmu_mode while
> >> + * they are in use.
> >> + * vpmu_mode can be safely updated while dom0's VPMUs are active and
> >> + * so we don't need to include it in the count.
> >> + */
> >> +if ( !is_hardware_domain(v->domain) &&
> >> +(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
> >> +{
> >> +vpmu_count++;
> >> +vpmu_set(vcpu_vpmu(v), VPMU_AVAILABLE);
> >> +}
> >> +
Re: [Xen-devel] [PATCH v2 3/3] x86/vmx: fix vmentry failure with TSX bits in LBR
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, February 21, 2017 7:25 PM
>
> On 21/02/17 09:13, Tian, Kevin wrote:
> >> @@ -2618,6 +2630,56 @@ static const struct lbr_info
> >> *last_branch_msr_get(void)
> >> return NULL;
> >> }
> >>
> >> +enum
> >> +{
> >> +LBR_FORMAT_32 = 0x0, /* 32-bit record format */
> >> +LBR_FORMAT_LIP= 0x1, /* 64-bit LIP record format */
> >> +LBR_FORMAT_EIP= 0x2, /* 64-bit EIP record format */
> >> +LBR_FORMAT_EIP_FLAGS = 0x3, /* 64-bit EIP, Flags */
> >> +LBR_FORMAT_EIP_FLAGS_TSX = 0x4, /* 64-bit EIP, Flags, TSX */
> >> +LBR_FORMAT_EIP_FLAGS_TSX_INFO = 0x5, /* 64-bit EIP, Flags, TSX,
> >> LBR_INFO
> */
> >> +LBR_FORMAT_EIP_FLAGS_CYCLES = 0x6, /* 64-bit EIP, Flags, Cycles */
> >> +};
> >> +
> >> +#define LBR_FROM_SIGNEXT_2MSB ((1ULL << 59) | (1ULL << 60))
> >> +
> >> +static bool __read_mostly vmx_lbr_tsx_fixup_needed;
> >> +static uint32_t __read_mostly lbr_from_start;
> >> +static uint32_t __read_mostly lbr_from_end;
> >> +static uint32_t __read_mostly lbr_lastint_from;
> >> +
> >> +static void __init vmx_lbr_tsx_fixup_check(void)
> >> +{
> >> +bool tsx_support = cpu_has_hle || cpu_has_rtm;
> >> +uint64_t caps;
> >> +uint32_t lbr_format;
> >> +
> >> +/* Fixup is needed only when TSX support is disabled ... */
> >> +if ( tsx_support )
> >> +return;
> > !tsx_support
>
> The original code is correct. This problem only manifests when TSX is
> unavailable.
>
yes. my bad.
> >
> >> +
> >> +if ( !cpu_has_pdcm )
> >> +return;
> > combine two ifs into one
> >
> >> +
> >> +rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
> >> +lbr_format = caps & LBR_FORMAT_MSR_IA32_PERF_CAP;
> >> +
> >> +/* ... and the address format of LBR includes TSX bits 61:62 */
> > what's "..."?
>
> From the previous comment.
>
> >
> >> +if ( lbr_format == LBR_FORMAT_EIP_FLAGS_TSX )
> >> +{
> >> +const struct lbr_info *lbr = last_branch_msr_get();
> >> +
> >> +if ( lbr == NULL )
> >> +return;
> > move above check before rdmsrl. At least avoid one unnecessary
> > msr read when LBR is not available.
>
> Which check and which rdmsr? In reality, if cpu_has_pdcm is set, we
> would always expect to have LBR.
move above 4 lines before reading PERF_CAPABILITIES. but
looks not necessary after another thought.
>
> >
> >> +
> >> +lbr_lastint_from = lbr[LBR_LASTINT_FROM_IDX].base;
> >> +lbr_from_start = lbr[LBR_LASTBRANCH_FROM_IDX].base;
> >> +lbr_from_end = lbr_from_start +
> >> lbr[LBR_LASTBRANCH_FROM_IDX].count;
> >> +
> >> +vmx_lbr_tsx_fixup_needed = true;
> >> +}
> >> +}
> >> +
> >> static int is_last_branch_msr(u32 ecx)
> >> {
> >> const struct lbr_info *lbr = last_branch_msr_get();
> >> @@ -2876,7 +2938,11 @@ static int vmx_msr_write_intercept(unsigned int msr,
> uint64_t
> >> msr_content)
> >> for ( ; (rc == 0) && lbr->count; lbr++ )
> >> for ( i = 0; (rc == 0) && (i < lbr->count); i++ )
> >> if ( (rc = vmx_add_guest_msr(lbr->base + i)) == 0 )
> >> +{
> >> vmx_disable_intercept_for_msr(v, lbr->base + i,
> MSR_TYPE_R |
> >> MSR_TYPE_W);
> >> +if ( vmx_lbr_tsx_fixup_needed )
> >> +v->arch.hvm_vmx.lbr_tsx_fixup_enabled = true;
> >> +}
> >> }
> >>
> >> if ( (rc < 0) ||
> >> @@ -3897,6 +3963,27 @@ out:
> >> }
> >> }
> >>
> >> +static void vmx_lbr_tsx_fixup(void)
> >> +{
> >> +struct vcpu *curr = current;
> >> +unsigned int msr_count = curr->arch.hvm_vmx.msr_count;
> >> +struct vmx_msr_entry *msr_area = curr->arch.hvm_vmx.msr_area;
> >> +struct vmx_msr_entry *msr;
> >> +
> >> +if ( (msr = vmx_find_msr(lbr_from_start, VMX_GUEST_MSR)) != NULL )
> > Curious whether NULL is a valid situation here. If not we need handle it.
> > Otherwise please ignore this comment.
>
> It is safer in the case that this function gets called and there are no
> LBR MSRs in the load list.
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/x86: ensure copying to L1 guest in update_runstate_area()
On 02/22/17 09:28 +0800, Haozhong Zhang wrote: > On 02/21/17 02:15 -0700, Jan Beulich wrote: > > >>> On 21.02.17 at 03:11, wrote: [..] > > > + * > > > + * Therefore, we clear the nested guest flag before > > > __raw_copy_to_guest() > > > + * and __copy_to_guest(), and restore the flag after all guest copy. > > > + */ > > > +if ( is_hvm_vcpu(v) && paging_mode_hap(v->domain) ) > > I think it would be clearer to use nestedhvm_enabled() here. > > has_hvm_container_vcpu() > > Nested HVM is only available to HVM domain, so I think is_hvm_vcpu(v) is > enough. > > > > > And why is this HAP-specific? > > > > IIUC, nested HVM relies on HAP. For nested SVM, I find the following check in hvmop_set_param(): case HVM_PARAM_NESTEDHVM: if ( cpu_has_svm && !paging_mode_hap(d) && a.value ) rc = -EINVAL; I don't find the similar check for nested VMX here and in vvmx.c. Though L1 HVM domain w/ nestedhvm=1 and hap=0 can boot up on Intel machine (because of the lack of above check?), starting L2 guest does crash L1 at the very beginning and L0 Xen reports the following debug messages: (XEN) realmode.c:111:d18v9 Failed to emulate insn. (XEN) Real-mode emulation failed: d18v9 Real @ f000:fff0 -> (XEN) domain_crash called from realmode.c:157 (XEN) Domain 18 (vcpu#9) crashed on cpu#29: (XEN) [ Xen-4.9-unstable x86_64 debug=y Not tainted ] (XEN) CPU:29 (XEN) RIP:f000:[] (XEN) RFLAGS: 0002 CONTEXT: hvm guest (d18v9) (XEN) rax: rbx: rcx: (XEN) rdx: 0f61 rsi: rdi: (XEN) rbp: rsp: r8: (XEN) r9: r10: r11: (XEN) r12: r13: r14: (XEN) r15: cr0: 0030 cr4: 2050 (XEN) cr3: feffc000 cr2: (XEN) ds: es: fs: gs: ss: cs: f000 I haven't dug into this problem, but I suspect there would be other bugs when using nested VMX w/o HAP. Maybe we should add a similar check in hvmop_set_param() for nested VMX as well. Kevin, any comments? Thanks, Haozhong ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/x86: ensure copying to L1 guest in update_runstate_area()
On 02/21/17 02:15 -0700, Jan Beulich wrote: > >>> On 21.02.17 at 03:11, wrote: > > For a HVM domain, if a vcpu is in the nested guest mode, > > __raw_copy_to_guest() and __copy_to_guest() used by > > update_runstate_area() will copy data to L2 guest other than L1 guest. > > > > Besides copying to the wrong address, this bug also causes crash in > > the code path: > > context_switch(prev, next) > > _update_runstate_area(next) > > update_runstate_area(next) > > __raw_copy_to_guest(...) > > ... > > __hvm_copy(...) > > paging_gva_to_gfn(...) > > nestedhap_walk_L1_p2m(...) > > nvmx_hap_walk_L1_p2m(..) > > vmx_vmcs_enter(v) [ v = next ] > > vmx_vmcs_try_enter(v) [ v = next ] > > if ( likely(v == current) ) > > return v->arch.hvm_vmx.vmcs_pa == > > this_cpu(current_vmcs); > > vmx_vmcs_try_enter() will fail and trigger the assert in > > vmx_vmcs_enter(), if vcpu 'next' is in the nested guest mode and is > > being scheduled to another CPU. > > > > This commit temporally clears the nested guest flag before all > > __raw_copy_to_guest() and __copy_to_guest() in update_runstate_area(), > > and restores the flag after those guest copy operations. > > Nice catch, but doesn't the same apply to > update_secondary_system_time() then? > Yes, I'll apply the same change to update_secondary_system_time(). > > @@ -1931,10 +1932,29 @@ bool_t update_runstate_area(struct vcpu *v) > > bool_t rc; > > smap_check_policy_t smap_policy; > > void __user *guest_handle = NULL; > > +bool nested_guest_mode = 0; > > false will change > > > if ( guest_handle_is_null(runstate_guest(v)) ) > > return 1; > > > > +/* > > + * Must be before all following __raw_copy_to_guest() and > > __copy_to_guest(). > > + * > > + * Otherwise, if 'v' is in the nested guest mode, paging_gva_to_gfn() > > called > > + * from __raw_copy_to_guest() and __copy_to_guest() will treat the > > target > > + * address as L2 gva, and __raw_copy_to_guest() and __copy_to_guest() > > will > > + * consequently copy runstate to L2 guest other than L1 guest. > > ... rather than ... ditto > > > + * > > + * Therefore, we clear the nested guest flag before > > __raw_copy_to_guest() > > + * and __copy_to_guest(), and restore the flag after all guest copy. > > + */ > > +if ( is_hvm_vcpu(v) && paging_mode_hap(v->domain) ) > > has_hvm_container_vcpu() Nested HVM is only available to HVM domain, so I think is_hvm_vcpu(v) is enough. > > And why is this HAP-specific? > IIUC, nested HVM relies on HAP. > > @@ -1971,6 +1991,9 @@ bool_t update_runstate_area(struct vcpu *v) > > > > smap_policy_change(v, smap_policy); > > > > +if ( nested_guest_mode ) > > Can we have an unlikely() here please? will add Thanks, Haozhong ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.6-testing baseline-only test] 68589: regressions - FAIL
This run is configured for baseline tests only. flight 68589 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68589/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-220 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 68567 test-xtf-amd64-amd64-2 33 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 68567 test-xtf-amd64-amd64-244 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 68567 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 14 guest-saverestore.2 fail REGR. vs. 68567 test-amd64-i386-xl-qemuu-debianhvm-amd64 14 guest-saverestore.2 fail REGR. vs. 68567 test-amd64-amd64-xl-qemut-winxpsp3 9 windows-install fail REGR. vs. 68567 Regressions which are regarded as allowable (not blocking): test-xtf-amd64-amd64-1 20 xtf/test-hvm32-invlpg~shadow fail like 68567 test-xtf-amd64-amd64-1 33 xtf/test-hvm32pae-invlpg~shadow fail like 68567 test-xtf-amd64-amd64-1 44 xtf/test-hvm64-invlpg~shadow fail like 68567 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 68567 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 68567 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 68567 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 68567 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 68567 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 68567 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68567 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-4 63 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-5 63 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-1 63 xtf/test-pv32pae-xsa-194 fail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-xtf-amd64-amd64-2 63 xtf/test-pv32pae-xsa-194 fail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-xtf-amd64-amd64-3 63 xtf/test-pv32pae-xsa-194 fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass version targeted for testing: xen 35d6d7bbb428f8a33d39d851d7d60d40a3605a58 baseline version: xen 8e04cb25d9634995fe9b37d05c63cdb4ce8c205e Last test of basis68567 2017-02-16 13:47:22 Z5 days Testing same since68589 2017-02-21 12:43:55 Z0 days1 attempts People who touched revisions under test: Andrew Cooper David Woodhouse George Dunlap Jan Beulich Kevin Tian Sergey Dyasli Tamas K Lengyel jobs: build-amd64-xsm pass build-armhf-xsm
[Xen-devel] [seabios test] 105952: regressions - FAIL
flight 105952 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/105952/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 105928 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105928 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105928 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass version targeted for testing: seabios 8f598a4641f98cf503653f80c779793d91c95a84 baseline version: seabios c83e15b60b7c59552a44d71d0582f2d62a6084a7 Last test of basis 105928 2017-02-20 16:14:16 Z1 days Testing same since 105952 2017-02-21 14:45:36 Z0 days1 attempts People who touched revisions under test: Ben Warren Kevin O'Connor 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-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-qemuu-nested-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail test-amd64-amd64-xl-qemuu-winxpsp3 pass test-amd64-i386-xl-qemuu-winxpsp3pass 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 Not pushing. commit 8f598a4641f98cf503653f80c779793d91c95a84 Author: Ben Warren Date: Mon Feb 20 19:56:19 2017 -0800 QEMU fw_cfg: Write fw_cfg back on S3 resume Any pointers to BIOS-allocated memory that were written back to QEMU fw_cfg files are replayed when resuming from S3 sleep. Signed-off-by: Ben Warren Reviewed-by: Laszlo Ersek Reviewed-by: Igor Mammedov Signed-off-by: Kevin O'Connor commit 336b60bb10196adf287489cca4fd17092d9fac5e Author: Ben Warren Date: Mon Feb 20 19:56:18 2017 -0800 QEMU fw_cfg: Add functions for accessing files by key Due to memory contraints, when resuming from S3 the fw_cfg "files" API isn't available. This adds a simple API to get a file 'key', and to write to the file using the key as a reference. Signed-off-by: Ben Warren Reviewed-by: Igor Mammedov Reviewed-by: Laszlo Ersek commit bb9cbbcabc37665cb645cacd1cfefbfe1f4364ab Author: Ben Warren Date: Mon Feb 20 19:56:17 2017 -0800 QEMU fw_cfg: Add command to write back address of file This command is similar to ADD_POINTER, but instead of patching memory, it writes the pointer back to QEMU over the DMA interface. Signed-off-by: Ben Warren Reviewed-by: Laszlo Ersek Reviewed-by: Igor Mammedov commit e5bebc77d2a9dfa67cda100b67d787c3ebdb5397 Author: Ben Warren Date: Mon Feb 20 19:56:16 2017 -0800 romfile-loader: Switch
Re: [Xen-devel] [xen-4.7-testing test] 105948: regressions - FAIL
On 21/02/2017 23:45, osstest service owner wrote:
> flight 105948 xen-4.7-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/105948/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10 fail REGR. vs.
> 105855
From
http://logs.test-lab.xenproject.org/osstest/logs/105948/test-amd64-amd64-xl-credit2/serial-nobling0.log
around Feb 21 20:32:01.481626
(XEN) csched2_vcpu_insert: Inserting d5v0
(XEN) csched2_vcpu_insert: Inserting d5v1
(XEN) csched2_vcpu_insert: Inserting d5v2
(XEN) csched2_vcpu_insert: Inserting d5v3
(XEN) Assertion 'd->cpupool != NULL' failed at
...5948.build-amd64/xen/xen/include/xen/sched-if.h:200
(XEN) [ Xen-4.7.2-pre x86_64 debug=y Not tainted ]
(XEN) CPU:14
(XEN) RIP:e008:[]
sched_credit2.c#vcpu_is_migrateable+0x22/0x9a
(XEN) RFLAGS: 00010046 CONTEXT: hypervisor
(XEN) rax: 8304573bc000 rbx: 83047f114f10 rcx: 83007baca000
(XEN) rdx: rsi: 83023fed0458 rdi: 83047f114f10
(XEN) rbp: 830473fffd60 rsp: 830473fffd40 r8: 14a138bf
(XEN) r9: 14a538bf r10: 00021e54 r11: 0f0f0f0f0f0f0f0f
(XEN) r12: 83047f114190 r13: 000e r14: 82d0802e66c0
(XEN) r15: 83023fed cr0: 80050033 cr4: 003526e4
(XEN) cr3: 000457499000 cr2: 880002810288
(XEN) ds: es: fs: gs: ss: e010 cs: e008
(XEN) Xen code around
(sched_credit2.c#vcpu_is_migrateable+0x22/0x9a):
(XEN) 8b 50 68 48 85 d2 75 02 <0f> 0b 49 89 f4 48 89 fb 48 8d 05 81 52
21 00 48
(XEN) Xen stack trace from rsp=830473fffd40:
(XEN)0006 83047f114f10 83047f114190 83023fed0498
(XEN)830473fffe20 82d080129763 830473fffde0 82d0802e66c0
(XEN)83023fed 83023fed 8304000e 8304000e
(XEN)0007000e 00528d5c4e92 830473fffdc8 830473fffe68
(XEN)82d080130110 02a5a4fa
(XEN)83023fed0960 83023fed0458 0002 8300679fc000
(XEN)82d08033c140 00528d5c4e92 83023fed0964 000e
(XEN)830473fffeb0 82d08012c17e a6671e870002 83023ff70160
(XEN)000e00fffe60 83023ff70140 830473fffe60 82d0801301a1
(XEN)830473fffeb0 82d0801330ad 830473fffef0 82d0801bb4a2
(XEN)0010679fc000 82d080313180 82d080312a80
(XEN)830473ff 8304677f2000 830473fffee0 82d08012f8bd
(XEN)830473ff 83007bad 83023fec2000
(XEN)830473fffef0 82d08012f912 83047310 82d080164b17
(XEN)82d08012f912 8300679fc000 830473fffdd8
(XEN)81c01fd8 81c01fd8 81c01e68
(XEN) 0246 00528d4bace3
(XEN) 810013aa 81c319a0
(XEN)deadbeef deadbeef 0100 810013aa
(XEN)e033 0246 81c01e50 e02b
(XEN) Xen call trace:
(XEN)[] sched_credit2.c#vcpu_is_migrateable+0x22/0x9a
(XEN)[] sched_credit2.c#csched2_schedule+0x823/0xb4e
(XEN)[] schedule.c#schedule+0x108/0x609
(XEN)[] softirq.c#__do_softirq+0x7f/0x8a
(XEN)[] do_softirq+0x13/0x15
(XEN)[] domain.c#idle_loop+0x55/0x62
(XEN)
(XEN)
(XEN)
(XEN) Panic on CPU 14:
(XEN) Assertion 'd->cpupool != NULL' failed at
...5948.build-amd64/xen/xen/include/xen/sched-if.h:200
(XEN)
(XEN)
(XEN) Manual reset required ('noreboot' specified)
I am guessing the most recent credit2 backports weren't quite so safe?
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.7-testing test] 105948: regressions - FAIL
flight 105948 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105948/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10 fail REGR. vs. 105855 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105855 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105855 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105855 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 105855 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105855 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 105855 test-amd64-amd64-xl-rtds 9 debian-install fail like 105855 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass build-arm64-xsm 5 xen-buildfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass build-arm64-pvops 5 kernel-build fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: xen 8a9dfe392702cb987cab725fbda7345f4c3053da baseline version: xen 758378233b0b5d79a29735d95dc72410ef2f19aa Last test of basis 105855 2017-02-16 15:36:15 Z5 days Testing same since 105924 2017-02-20 15:11:38 Z1 days3 attempts People who touched revisions under test: Andrew Cooper Dario Faggioli David Woodhouse George Dunlap Jan Beulich Kevin Tian Sergey Dyasli Tamas K Lengyel jobs: build-amd64-xsm pass build-arm64-xsm fail
[Xen-devel] [PATCH v3] ring.h: introduce macros to handle monodirectional rings with multiple req sizes
This patch introduces macros, structs and functions to handle rings in
the format described by docs/misc/pvcalls.markdown and
docs/misc/9pfs.markdown. The index page (struct __name##_data_intf)
contains the indexes and the grant refs to setup two rings.
Indexes page
+--+
|@0 $NAME_data_intf: |
|@76: ring_order = 1 |
|@80: ref[0]+ |
|@84: ref[1]+ |
| | |
| | |
+--+
|
v (data ring)
+---+---+
| @0->4098: in |
| ref[0] |
|---|
| @4099->8196: out |
| ref[1] |
+---+
$NAME_read_packet and $NAME_write_packet are provided to read or write
any data struct from/to the ring. In pvcalls, they are unused. In xen
9pfs, they are used to read or write the 9pfs header. In other protocols
they could be used to read/write the whole request structure. See
docs/misc/9pfs.markdown:Ring Usage to learn how to check how much data
is on the ring, and how to handle notifications.
There is a ring_size parameter to most functions so that protocols using
these macros don't have to have a statically defined ring order at build
time. In pvcalls for example, each new ring could have a different
order.
These macros don't help you share the indexes page or the event channels
needed for notifications. You can do that with other out of band
mechanisms, such as xenstore or another ring.
It is not possible to use a macro to define another macro with a
variable name. For this reason, this patch introduces static inline
functions instead, that are not C89 compliant. Additionally, the macro
defines a struct with a variable sized array, which is also not C89
compliant.
Signed-off-by: Stefano Stabellini
CC: konrad.w...@oracle.com
CC: andr2...@gmail.com
CC: oleksandr_andrushche...@epam.com
CC: andrii.ani...@gmail.com
CC: vlad.babc...@gmail.com
CC: al1...@gmail.com
CC: jocula...@gmail.com
---
Changes in v3:
- mention C89 compliance breakages
- constify parameters
- use unsigned chars for buffers
- add two macros, one doesn't define the struct
Changes in v2:
- fix typo
- remove leading underscores from names
- use UL
- do not parenthesize parameters
- code readability improvements
Give a look at the following branch to see how they are used with
pvcalls and xen-9pfs (the drivers are still work in progress):
git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 9pfs-async-v6
---
---
xen/include/public/io/ring.h | 120 +++
1 file changed, 120 insertions(+)
diff --git a/xen/include/public/io/ring.h b/xen/include/public/io/ring.h
index 801c0da..4d36f06 100644
--- a/xen/include/public/io/ring.h
+++ b/xen/include/public/io/ring.h
@@ -313,6 +313,126 @@ typedef struct __name##_back_ring __name##_back_ring_t
(_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r); \
} while (0)
+
+/*
+ * DEFINE_XEN_FLEX_RING_AND_INTF defines two monodirectional rings and
+ * functions to check if there is data on the ring, and to read and
+ * write to them.
+ *
+ * DEFINE_XEN_FLEX_RING is similar to DEFINE_XEN_FLEX_RING_AND_INTF, but
+ * does not define the indexes page. As different protocols can have
+ * extensions to the basic format, this macro allow them to define their
+ * own struct.
+ *
+ * XEN_FLEX_RING_SIZE
+ * Convenience macro to calculate the size of one of the two rings
+ * from the overall order.
+ *
+ * $NAME_mask
+ * Function to apply the size mask to an index, to reduce the index
+ * within the range [0-size].
+ *
+ * $NAME_read_packet
+ * Function to read a defined amount of data from the ring. The amount
+ * of data read is sizeof(__packet_t).
+ *
+ * $NAME_write_packet
+ * Function to write a defined amount of data to the ring. The amount
+ * of data to write is sizeof(__packet_t).
+ *
+ * $NAME_data_intf
+ * Indexes page, shared between frontend and backend. It also
+ * contains the array of grant refs.
+ *
+ * $NAME_queued
+ * Function to calculate how many bytes are currently on the ring,
+ * ready to be read. It can also be used to calculate how much free
+ * space is currently on the ring (ring_size - $NAME_queued()).
+ */
+#define XEN_FLEX_RING_SIZE(order) \
+(1UL << (order + PAGE_SHIFT - 1))
+
+#define DEFINE_XEN_FLEX_RING_AND_INTF(name, packet_t) \
+struct name##_data_intf { \
+RING_IDX in_cons, in_prod;\
+ \
Re: [Xen-devel] [PATCH] ring.h: introduce macros to handle monodirectional rings with multiple req sizes
On Tue, 21 Feb 2017, Jan Beulich wrote:
> >>> On 21.02.17 at 00:26, wrote:
> > On Mon, 20 Feb 2017, Jan Beulich wrote:
> >> >>> On 17.02.17 at 23:38, wrote:
> >> But the use of inline functions here is questionable
> >> in the first place - so far there are none, as they're not standard
> >> C89. Granted they are being used in a macro only, so won't cause
> >> immediate issues for code not using the macros, but anyway.
> >
> > I did it because it is not possible to use a macro to define another
> > macro with a variable name. In other words, the following does not work:
> >
> > #define DEFINE_XEN_FLEX_RING(name, packet_t)
> > \
> > #define name##_mask(idx, ring_size) (idx & (ring_size - 1))
> >
> > I prefer to drop C89 compliance to keep cleaner code, but if you have
> > better suggestions, I would be happy to hear them.
>
> Well, okay then, but please add a respective remark to the commit
> message then.
OK
> >> > +static inline void __name##_read_packet(char *buf,
> >> > \
> >>
> >> const
> >
> > We cannot use const char *buf, because we are about to pass buf to
> > memcpy.
>
> I don't understand: memcpy()'s second parameter is const.
Ah, right
> >> > +RING_IDX *masked_prod, RING_IDX *masked_cons,
> >> > \
> >>
> >> You don't update *masked_prod - why do you need a pointer here?
> >
> > When using this functions in pvcalls and xen-9pfs, I found that it was
> > less confusing for me if the two index parameters had the same type. In
> > fact, I started with what you suggested, then changed it back to this.
>
> I don't find this a convincing argument. The parameters will differ
> in constness anyway due to the different transfer direction, and
> using an extra layer of indirection just for aesthetic reasons seems
> at least odd to me.
All right, I'll make the change
> >> > +struct __name##_data {
> >> > \
> >> > +char *in; /* half of the allocation */
> >> > \
> >> > +char *out; /* half of the allocation */
> >> > \
> >>
> >> Why plain char? Void would seem the most neutral option here, but
> >> if arithmetic needs doing inside the header, then unsigned char may
> >> need to be used.
> >
> > The types here should match the type of the "buf" parameter used in the
> > read/write_packet functions. We cannot use void as we do arithmetic. If
> > you think unsigned char is more appropriate, I'll also change the type
> > of the buf arguments elsewhere.
>
> Yes please - plain char is mainly meant for use with strings, not
> arbitrary binary data.
OK
> >> > +struct __name##_data_intf {
> >> > \
> >> > +RING_IDX in_cons, in_prod;
> >> > \
> >> > +
> >> > \
> >> > +uint8_t pad1[56];
> >> > \
> >> > +
> >> > \
> >> > +RING_IDX out_cons, out_prod;
> >> > \
> >> > +
> >> > \
> >> > +uint8_t pad2[56];
> >> > \
> >> > +
> >> > \
> >> > +RING_IDX ring_order;
> >> > \
> >> > +grant_ref_t ref[];
> >> > \
> >> > +};
> >> > \
> >>
> >> Above you talk about the option of defining private _data_intf
> >> structures. How is that supposed to work when you define a
> >> suitably named structure already here? Other than #define-s
> >> one can't undo such a type definition.
> >
> > Yes, but it is always possible to use a different name. For example,
> > this is what I did in the pvcalls header:
> >
> > struct __pvcalls_data_intf {
> > RING_IDX in_cons, in_prod, in_error;
> >
> > uint8_t pad1[52];
> >
> > RING_IDX out_cons, out_prod, out_error;
> >
> > uint8_t pad2[52];
> >
> > RING_IDX ring_order;
> > grant_ref_t ref[];
> > };
> >
> > This struct is only here as a reference, we don't have to actually
> > define it in ring.h. If you think it's best, I could introduce it only
> > as a comment.
>
> How about having two variants of the macro - one (the base)
> version without this, and a second invoking the first and adding
> this?
Sure
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] ring.h: introduce macros to handle monodirectional rings with multiple req sizes
On Tue, 21 Feb 2017, Jan Beulich wrote:
> >>> On 21.02.17 at 02:32, wrote:
> > +static inline void name##_read_packet(char *buf,
> >\
> > +RING_IDX *masked_prod, RING_IDX *masked_cons,
> >\
>
> The const/indirection problems is still there.
I'll fix
> > +static inline void name##_write_packet(char *buf,
> >\
> > +RING_IDX *masked_prod, RING_IDX *masked_cons,
> >\
> > +RING_IDX ring_size, packet_t *h) {
> >\
>
> Same here - it being a pointer now, the last parameter should then
> be a pointer to const (and you shouldn't cast away constness below).
OK
> > +struct name##_data_intf {
> >\
> > +RING_IDX in_cons, in_prod;
> >\
> > +
> >\
> > +uint8_t pad1[56];
> >\
> > +
> >\
> > +RING_IDX out_cons, out_prod;
> >\
> > +
> >\
> > +uint8_t pad2[56];
> >\
> > +
> >\
> > +RING_IDX ring_order;
> >\
> > +grant_ref_t ref[];
> >\
> > +};
> >
>
> The use of a variable sized array here should also be mentioned as
> an exception from the C89-compatibility rule in the description.
Makes sense
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 105946: regressions - FAIL
flight 105946 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/105946/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail REGR. vs. 105933 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105933 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105933 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 105933 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 105933 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105933 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 105933 test-amd64-amd64-xl-rtds 9 debian-install fail like 105933 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105933 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass build-arm64-xsm 5 xen-buildfail never pass build-arm64 5 xen-buildfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass build-arm64-pvops 5 kernel-build fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass version targeted for testing: xen 5dbd60e16a1f29b9f1f84088c5cab1be2dac7a7a baseline version: xen 2f5af2c962c05b789bdd65b46c74711e903f86d0 Last test of basis 105933 2017-02-20 20:13:35 Z1 days Testing same since 105946 2017-02-21 10:19:53 Z0 days1 attempts People who touched revisions under test: Andrew Cooper George Dunlap jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm
Re: [Xen-devel] kpartx for raisin hvm tests
On Tue, 21 Feb 2017, Géza Gémes wrote: > Hi, > > I've tried to run the raisin test suite, while pv tests pass the hvm tests > fail. I've identified a number of problems, starting with two small disk size > to formating the whole disk and then being unable to install grub to the boot > sector. I've trace down these problems into the incorrect invocation of the > _create_loop_device function in scripts/lopartsetup. > > My question: Will it be acceptable if I would replace this part of the code > with a kpartx call? Or introducing kpartx is a too big change in the list of > dependencies? I understand that kpartx makes things much easier, but before introducing it as a dependency, I would like to understand this problem a bit better. Why is _create_loop_device invoked incorrectly? Is it index or offset that is calculate incorrectly?___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/4] tools/libxendevicemodel: introduce the new library
Wei Liu, on lun. 20 févr. 2017 15:20:08 +, wrote: > On Mon, Feb 20, 2017 at 03:14:27PM +, Paul Durrant wrote: > > > From: Wei Liu [mailto:wei.l...@citrix.com] > > > > > [2] > > > > > http://xenbits.xen.org/gitweb/?p=people/pauldu/mini-os.git;a=commit;h=41c9f2ae > > > > > > > > > > > Need an ack from Samuel Acked-by: Samuel Thibault Samuel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xtf test] 105954: all pass - PUSHED
flight 105954 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105954/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf f3cbcfed8a591b5fd9ec99bb7252785e2235179d
baseline version:
xtf 2b8c78575cb534908ccc8824d76904376b9c38a5
Last test of basis 105859 2017-02-16 18:13:16 Z5 days
Testing same since 105954 2017-02-21 15:43:54 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
jobs:
build-amd64-xtf pass
build-amd64 pass
build-amd64-pvopspass
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 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=xtf
+ revision=f3cbcfed8a591b5fd9ec99bb7252785e2235179d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xtf
f3cbcfed8a591b5fd9ec99bb7252785e2235179d
+ branch=xtf
+ revision=f3cbcfed8a591b5fd9ec99bb7252785e2235179d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xtf
+ xenbranch=xen-unstable
+ '[' xxtf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' xf3cbcfed8a591b5fd9ec99bb7252785e2235179d = 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-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x
[Xen-devel] [ovmf test] 105949: all pass - PUSHED
flight 105949 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105949/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 85520606ad459ba7d825c7ea5f225cffa1dbe95b
baseline version:
ovmf 5af4388433e13ffeda980116d92f4230c79e483d
Last test of basis 105937 2017-02-21 01:16:07 Z0 days
Testing same since 105949 2017-02-21 12:00:06 Z0 days1 attempts
People who touched revisions under test:
Dandan Bi
Hao Wu
Jiewen Yao
Ruiyu Ni
Yao Jiewen
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=85520606ad459ba7d825c7ea5f225cffa1dbe95b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
85520606ad459ba7d825c7ea5f225cffa1dbe95b
+ branch=ovmf
+ revision=85520606ad459ba7d825c7ea5f225cffa1dbe95b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x85520606ad459ba7d825c7ea5f225cffa1dbe95b = 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
++ : os
[Xen-devel] [PATCH] iommu: Elaborate the usage of RMRR specification on the command line.
As some users have suggested, elaborate the usage of RMRR specification on the command line, and provide a usage example. Signed-off-by: Venu Busireddy --- docs/misc/xen-command-line.markdown |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown index 3acbb33..77e0a20 100644 --- a/docs/misc/xen-command-line.markdown +++ b/docs/misc/xen-command-line.markdown @@ -1406,6 +1406,15 @@ If segment of the first device is not specified, segment zero will be used. If other segments are not specified, first device segment will be used. If a segment is specified for other than the first device and it does not match the one specified for the first one, an error will be reported. + +'start' and 'end' values are page numbers (not full physical addresses). +If the values are not preceded by "0x", they are treated as decimal. + +Usage example: If there are two devices 0:0:1d.0 and 0:0:1a.0 that require +pages 0xd5d45 and 0xd5d46 to be reserved respectively, use: + +rmrr=0xd5d45=0:0:1d.0;0xd5d46=0:0:1a.0 + Note: grub2 requires to escape or use quotations if special characters are used, namely ';', refer to the grub2 documentation if multiple ranges are specified. -- 1.7.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable baseline-only test] 68587: regressions - trouble: blocked/broken/fail/pass
This run is configured for baseline tests only. flight 68587 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68587/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 3 host-install(3)broken REGR. vs. 68581 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 68581 test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail REGR. vs. 68581 test-armhf-armhf-libvirt-raw 14 guest-start/debian.repeat fail REGR. vs. 68581 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-rumprun-amd64 16 rumprun-demo-xenstorels/xenstorels.repeat fail REGR. vs. 68581 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 68581 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 68581 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 68581 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68581 test-amd64-amd64-qemuu-nested-intel 17 capture-logs/l1(17) fail like 68581 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 68581 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 9 windows-installfail like 68581 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-installfail like 68581 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 2 hosts-allocate broken never pass build-arm64-xsm 2 hosts-allocate broken never pass build-arm64-pvops 2 hosts-allocate broken never pass build-arm64 3 capture-logs broken never pass build-arm64-pvops 3 capture-logs broken never pass build-arm64-xsm 3 capture-logs broken never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: xen 2f5af2c962c05b789bdd65b46c74711e903f86d0 baseline version: xen 75da1b150e646bb9aaa26c5b2452f0c3e782d302 Last test of basis68581 2017-02-18 12:47:14 Z3 days Te
[Xen-devel] [qemu-mainline test] 105943: tolerable FAIL - PUSHED
flight 105943 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/105943/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105923 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105923 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105923 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105923 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 105923 test-amd64-amd64-xl-rtds 9 debian-install fail like 105923 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass build-arm64 5 xen-buildfail never pass build-arm64-xsm 5 xen-buildfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass build-arm64-pvops 5 kernel-build fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: qemuu56f9e46b841c7be478ca038d8d4085d776ab4b0d baseline version: qemuud514cfd763b271b4e97a9fc6adaabc8fd50084ab Last test of basis 105923 2017-02-20 12:15:43 Z1 days Testing same since 105931 2017-02-20 19:16:44 Z1 days2 attempts People who touched revisions under test: Anatoli Huseu1 Fabian Lesniak Frediano Ziglio Gerd Hoffmann Marc-André Lureau Markus Armbruster Peter Maydell Thomas Huth jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 fail build-armhf
[Xen-devel] [linux-linus test] 105941: regressions - FAIL
flight 105941 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/105941/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 59254 test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-qemut-debianhvm-amd64 13 guest-localmigrate fail REGR. vs. 59254 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail REGR. vs. 59254 test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-libvirt 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemut-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 59254 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-rtds 9 debian-installfail REGR. vs. 59254 test-armhf-armhf-xl-vhd 6 xen-bootfail baseline untested test-armhf-armhf-libvirt-raw 6 xen-bootfail baseline untested test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 59254 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass build-arm64-xsm 5 xen-buildfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass build-arm64 5 xen-buildfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass version targeted for testing: linux2bfe01eff4307409b95859e860261d0907149b61 baseline version: linux45820c294fe1b1a9df495d57f40585ef2d069a39 Last test of basis59254 2015-07-09 04:20:48 Z 593 days Failing since 59348 2015-07-10 04:24:05 Z 592 days 289 attempts Testing same since 105941 2017-02-21 07:28:32 Z0 days1 attempts 7637 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 fail build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt blocked build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops
Re: [Xen-devel] [PATCH v16 4/9] x86: add multiboot2 protocol support for EFI platforms
On Tue, Feb 21, 2017 at 08:19:53PM +0100, Daniel Kiper wrote: > This way Xen can be loaded on EFI platforms using GRUB2 and > other boot loaders which support multiboot2 protocol. > > Signed-off-by: Daniel Kiper > --- > v16 - suggestions/fixes: > - improve comments in error handling > (suggested by Jan Beulich). Diff between v15 and v16: diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S index 6352142..a2177c3 100644 --- a/xen/arch/x86/boot/head.S +++ b/xen/arch/x86/boot/head.S @@ -133,16 +133,30 @@ not_multiboot: mov $(sym_phys(.Lbad_ldr_msg)),%esi # Error message jmp .Lget_vtb .Lmb2_no_st: +/* + * Here we are on EFI platform. vga_text_buffer was zapped earlier + * because there is pretty good chance that VGA is unavailable. + */ mov $(sym_phys(.Lbad_ldr_nst)),%esi # Error message jmp .Lget_vtb .Lmb2_no_ih: +/* Ditto. */ mov $(sym_phys(.Lbad_ldr_nih)),%esi # Error message jmp .Lget_vtb .Lmb2_no_bs: +/* + * Ditto. Additionally, here there is a chance that Xen was started + * via start label. Then reliable vga_text_buffer zap is impossible + * in Multiboot2 scanning loop and we have to zero %edi below. + */ mov $(sym_phys(.Lbad_ldr_nbs)),%esi # Error message xor %edi,%edi # No VGA text buffer jmp .Lsend_chr .Lmb2_efi_ia_32: +/* + * Here we are on EFI IA-32 platform. Then reliable vga_text_buffer zap is + * impossible in Multiboot2 scanning loop and we have to zero %edi below. + */ mov $(sym_phys(.Lbad_efi_msg)),%esi # Error message xor %edi,%edi # No VGA text buffer jmp .Lsend_chr @@ -393,18 +407,10 @@ __start: /* EFI IA-32 platforms are not supported. */ cmpl$MULTIBOOT2_TAG_TYPE_EFI32,MB2_tag_type(%ecx) -/* - * Here we should zap vga_text_buffer. However, we can disable - * VGA updates in simpler and more reliable way later. - */ je .Lmb2_efi_ia_32 /* Bootloader shutdown EFI x64 boot services. */ cmpl$MULTIBOOT2_TAG_TYPE_EFI64,MB2_tag_type(%ecx) -/* - * Here we should zap vga_text_buffer. However, we can disable - * VGA updates in simpler and more reliable way later. - */ je .Lmb2_no_bs /* Is it the end of Multiboot2 information? */ ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v16 7/9] x86: make Xen early boot code relocatable
Every multiboot protocol (regardless of version) compatible image must specify its load address (in ELF or multiboot header). Multiboot protocol compatible loader have to load image at specified address. However, there is no guarantee that the requested memory region (in case of Xen it starts at 2 MiB and ends at ~5 MiB) where image should be loaded initially is a RAM and it is free (legacy BIOS platforms are merciful for Xen but I found at least one EFI platform on which Xen load address conflicts with EFI boot services; it is Dell PowerEdge R820 with latest firmware). To cope with that problem we must make Xen early boot code relocatable and help boot loader to relocate image in proper way by suggesting, not requesting specific load addresses as it is right now, allowed address ranges. This patch does former. It does not add multiboot2 protocol interface which is done in "x86: add multiboot2 protocol support for relocatable images" patch. This patch changes following things: - %esi register is used as a storage for Xen image load base address; it is mostly unused in early boot code and preserved during C functions calls in 32-bit mode, - %fs is used as base for Xen data relative addressing in 32-bit code if it is possible; %esi is used for that thing during error printing because it is not always possible to properly and efficiently initialize %fs. Signed-off-by: Daniel Kiper --- v13 - suggestions/fixes: - move gdt_boot_descr to .init.data section (suggested by Jan Beulich). v12 - suggestions/fixes: - store Xen image load base address directly into %esi, - store Xen image load base address after x86_32_switch (suggested by Doug Goldstein), - improve commit message. v8 - suggestions/fixes: - use shld instead of mov and shr in BOOT_FS segment descriptor base address initialization (suggested by Jan Beulich), - simplify code updating frame addresses in page tables (suggested by Jan Beulich), - print Xen image base addresses using "%#lx" format (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich). v6 - suggestions/fixes: - leave static mapping of first 16 MiB in l2_identmap as is (suggested by Jan Beulich), - use xen_phys_start instead of xen_img_load_base_addr (suggested by Daniel Kiper and Jan Beulich), - simplify BOOT_FS segment descriptor base address initialization (suggested by Jan Beulich), - fix BOOT_FS segment limit (suggested by Jan Beulich), - do not rename sym_phys in this patch (suggested by Jan Beulich), - rename esi_offset/fs_offset to sym_esi/sym_fs respectively (suggested by Jan Beulich), - use add instead of lea in assembly error printing code (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich), - improve commit message (suggested by Jan Beulich), - various minor cleanups and fixes (suggested by Jan Beulich). v4 - suggestions/fixes: - do not relocate Xen image if boot loader did work for us (suggested by Andrew Cooper and Jan Beulich), - initialize xen_img_load_base_addr in EFI boot code too, - properly initialize trampoline_xen_phys_start, - calculate Xen image load base address in x86_64 code ourselves, (suggested by Jan Beulich), - change how and when Xen image base address is printed, - use %fs instead of %esi for relative addressing (suggested by Andrew Cooper and Jan Beulich), - create esi_offset and fs_offset() macros in assembly, - calculate mkelf32 argument automatically, - optimize and cleanup code, - improve comments, - improve commit message. v3 - suggestions/fixes: - improve segment registers initialization (suggested by Jan Beulich), - simplify Xen image load base address calculation (suggested by Jan Beulich), - use %esi and %r15d instead of %ebp to store Xen image load base address, - use %esi instead of %fs for relative addressing; this way we get shorter and simpler code, - rename some variables and constants (suggested by Jan Beulich), - improve comments (suggested by Konrad Rzeszutek Wilk), - improve commit message (suggested by Jan Beulich). --- xen/arch/x86/boot/head.S | 170 - xen/arch/x86/boot/trampoline.S|5 ++ xen/arch/x86/boot/x86_64.S| 21 +++-- xen/arch/x86/setup.c | 14 +-- xen/arch/x86/x86_64/asm-offsets.c |3 + xen/include/asm-x86/page.h|2 +- 6 files changed, 158 insertions(+), 57 deletions(-) diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S index b5d9ec8..658e40a 100644 --- a/xen/arch/x86/boot/head.S +++ b/xen/arch/x86/boot/head.S @@ -12,12 +12,15 @@ .code32 #define sym_phys(sym) ((sym) - __XEN_VIRT_START) +#define sym_esi(sym) sym_phys(sym)(%esi) +#define sym_fs(sym) %fs:sym_
[Xen-devel] [PATCH v16 8/9] x86/boot: rename sym_phys() to sym_offs()
This way macro name better describes its function.
Currently it is used to calculate symbol offset in
relation to the beginning of Xen image mapping.
However, value returned by sym_offs() for a given
symbol is not always equal its physical address.
There is no functional change.
Suggested-by: Jan Beulich
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
v8 - suggestions/fixes:
- improve commit message
(suggested by Jan Beulich).
---
xen/arch/x86/boot/head.S | 38 +++---
xen/arch/x86/boot/trampoline.S |2 +-
xen/arch/x86/boot/wakeup.S |4 ++--
xen/arch/x86/boot/x86_64.S | 18 +-
4 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 658e40a..dba336d 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -11,9 +11,9 @@
.text
.code32
-#define sym_phys(sym) ((sym) - __XEN_VIRT_START)
-#define sym_esi(sym) sym_phys(sym)(%esi)
-#define sym_fs(sym) %fs:sym_phys(sym)
+#define sym_offs(sym) ((sym) - __XEN_VIRT_START)
+#define sym_esi(sym) sym_offs(sym)(%esi)
+#define sym_fs(sym) %fs:sym_offs(sym)
#define BOOT_CS320x0008
#define BOOT_CS640x0010
@@ -96,7 +96,7 @@ multiboot2_header_start:
/* EFI64 Multiboot2 entry point. */
mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
- sym_phys(__efi64_mb2_start)
+ sym_offs(__efi64_mb2_start)
/* Multiboot2 header end tag. */
mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
@@ -118,7 +118,7 @@ multiboot2_header_start:
gdt_boot_descr:
.word 7*8-1
gdt_boot_base:
-.long sym_phys(trampoline_gdt)
+.long sym_offs(trampoline_gdt)
.long 0 /* Needed for 64-bit lgdt */
vga_text_buffer:
@@ -130,21 +130,21 @@ efi_platform:
.section .init.text, "ax", @progbits
bad_cpu:
-add $sym_phys(.Lbad_cpu_msg),%esi # Error message
+add $sym_offs(.Lbad_cpu_msg),%esi # Error message
jmp .Lget_vtb
not_multiboot:
-add $sym_phys(.Lbad_ldr_msg),%esi # Error message
+add $sym_offs(.Lbad_ldr_msg),%esi # Error message
jmp .Lget_vtb
.Lmb2_no_st:
/*
* Here we are on EFI platform. vga_text_buffer was zapped earlier
* because there is pretty good chance that VGA is unavailable.
*/
-add $sym_phys(.Lbad_ldr_nst),%esi # Error message
+add $sym_offs(.Lbad_ldr_nst),%esi # Error message
jmp .Lget_vtb
.Lmb2_no_ih:
/* Ditto. */
-add $sym_phys(.Lbad_ldr_nih),%esi # Error message
+add $sym_offs(.Lbad_ldr_nih),%esi # Error message
jmp .Lget_vtb
.Lmb2_no_bs:
/*
@@ -152,7 +152,7 @@ not_multiboot:
* via start label. Then reliable vga_text_buffer zap is impossible
* in Multiboot2 scanning loop and we have to zero %edi below.
*/
-add $sym_phys(.Lbad_ldr_nbs),%esi # Error message
+add $sym_offs(.Lbad_ldr_nbs),%esi # Error message
xor %edi,%edi # No VGA text buffer
jmp .Lsend_chr
.Lmb2_efi_ia_32:
@@ -160,7 +160,7 @@ not_multiboot:
* Here we are on EFI IA-32 platform. Then reliable vga_text_buffer
zap is
* impossible in Multiboot2 scanning loop and we have to zero %edi
below.
*/
-add $sym_phys(.Lbad_efi_msg),%esi # Error message
+add $sym_offs(.Lbad_efi_msg),%esi # Error message
xor %edi,%edi # No VGA text buffer
jmp .Lsend_chr
.Lget_vtb:
@@ -371,7 +371,7 @@ __start:
cli
/* Load default Xen image load base address. */
-mov $sym_phys(__image_base__),%esi
+mov $sym_offs(__image_base__),%esi
/* Bootloaders may set multiboot{1,2}.mem_lower to a nonzero value. */
xor %edx,%edx
@@ -543,8 +543,8 @@ trampoline_setup:
jnz 1f
/* Initialize BSS (no nasty surprises!). */
-mov $sym_phys(__bss_start),%edi
-mov $sym_phys(__bss_end),%ecx
+mov $sym_offs(__bss_start),%edi
+mov $sym_offs(__bss_end),%ecx
push%fs
pop %es
sub %edi,%ecx
@@ -617,22 +617,22 @@ trampoline_setup:
/* Apply relocations to bootstrap trampoline. */
mov sym_fs(trampoline_phys),%edx
-mov $sym_phys(__trampoline_rel_start),%edi
+mov $sym_offs(__trampoline_rel_start),%edi
1:
mov %fs:(%edi),%eax
add %edx,%fs:(%edi,%eax)
add $4,%edi
-cmp $sym_phys(__trampoline_rel_stop),%edi
+cmp $sym_offs(__trampoline_rel_stop),%edi
jb 1b
/* Patch in the tra
Re: [Xen-devel] [PATCH] xen/arm: introduce vwfi parameter
On 21/02/2017 18:30, Stefano Stabellini wrote: On Tue, 21 Feb 2017, Julien Grall wrote: Hi Stefano, On 21/02/17 17:49, Stefano Stabellini wrote: On Tue, 21 Feb 2017, Dario Faggioli wrote: On Tue, 2017-02-21 at 13:46 +, George Dunlap wrote: Oh, actually, if --which I only now realize may be what you are referring to, since you're talking about "guest burning its credits"-- you let the vCPU put the pCPU to sleep *but*, when it wakes up (or when the scheduler runs again for whatever reason), you charge to it for all the time the the pCPU was actually idle/sleeping, well, that may actually not break scheduling, or cause disruption to the service of other vCPUs But indeed I'd consider it rather counter intuitive a behavior. How can this be safe? There could be no interrupts programmed to wake up the pcpu at all. In fact, I don't think today there would be any, unless we set one up in Xen for the specific purpose of interrupting the pcpu sleep. I don't know the inner working of the scheduler, but does it always send an interrupt to other pcpu to schedule something? You still seem to assume that WFI/WFE is the only way to get a vCPU unscheduled. If that was the case it would be utterly wrong because you cannot expect a guest to use them. What if there are 2 vcpu pinned to the same pcpu? This cannot be fair. Why wouldn't it be fair? This is the same situation as a guest vCPU not using WFI/WFE. I read your suggestion as trapping WFI in Xen, then, depending on settings, executing WFI in the Xen trap handler to idle the pcpu. That doesn't work. But I take you suggested not trapping wfi (remove HCR_TWI), executing the instruction in guest context. That is what we used to do in the early days (before a780f750). It should be safe and possibly even quick. I'll rerun the numbers and let you know. My first suggestion was to emulate WFI in Xen, which I agree is not safe :). I think not trapping WFI will have the best performance but may impact the credit of the vCPU as mentioned by Dario and George. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v16 1/9] x86: add multiboot2 protocol support
Add multiboot2 protocol support. Alter min memory limit handling as we now may not find it from either multiboot (v1) or multiboot2. This way we are laying the foundation for EFI + GRUB2 + Xen development. Signed-off-by: Daniel Kiper Reviewed-by: Jan Beulich Reviewed-by: Doug Goldstein Reviewed-by: Andrew Cooper Tested-by: Doug Goldstein --- v13 - suggestions/fixes: - add Emacs file-local variables (suggested by Andrew Cooper). v12 - suggestions/fixes: - replace TABs with spaces in xen/include/xen/multiboot2.h (suggested by Doug Goldstein). v9 - suggestions/fixes: - use .L label instead of numeric one in multiboot2 data scanning loop; I hope that this change does not invalidate Jan's Reviewed-by (suggested by Jan Beulich). v8 - suggestions/fixes: - use sizeof(/) instead of sizeof() if it is possible (suggested by Jan Beulich). v7 - suggestions/fixes: - rename mbi_mbi/mbi2_mbi to mbi_reloc/mbi2_reloc respectively (suggested by Jan Beulich), - initialize mbi_out->flags using "|=" instead of "=" (suggested by Jan Beulich), - use sizeof(*mmap_dst) instead of sizeof(memory_map_t) if it makes sense (suggested by Jan Beulich). v6 - suggestions/fixes: - properly index multiboot2_tag_mmap_t.entries[] (suggested by Jan Beulich), - do not index mbi_out_mods[] beyond its end (suggested by Andrew Cooper), - reduce number of casts (suggested by Andrew Cooper and Jan Beulich), - add braces to increase code readability (suggested by Andrew Cooper). v5 - suggestions/fixes: - check multiboot2_tag_mmap_t.entry_size before multiboot2_tag_mmap_t.entries[] use (suggested by Jan Beulich), - properly index multiboot2_tag_mmap_t.entries[] (suggested by Jan Beulich), - use "type name[]" instad of "type name[0]" in xen/include/xen/multiboot2.h (suggested by Jan Beulich), - remove unneeded comment (suggested by Jan Beulich). v4 - suggestions/fixes: - avoid assembly usage in xen/arch/x86/boot/reloc.c, - fix boundary check issue and optimize for() loops in mbi2_mbi(), - move to stdcall calling convention, - remove unneeded typeof() from ALIGN_UP() macro (suggested by Jan Beulich), - add and use NULL definition in xen/arch/x86/boot/reloc.c (suggested by Jan Beulich), - do not read data beyond the end of multiboot2 information in xen/arch/x86/boot/head.S (suggested by Jan Beulich), - add :req to some .macro arguments (suggested by Jan Beulich), - use cmovcc if possible, - add .L to multiboot2_header_end label (suggested by Jan Beulich), - add .L to multiboot2_proto label (suggested by Jan Beulich), - improve label names (suggested by Jan Beulich). v3 - suggestions/fixes: - reorder reloc() arguments (suggested by Jan Beulich), - remove .L from multiboot2 header labels (suggested by Andrew Cooper, Jan Beulich and Konrad Rzeszutek Wilk), - take into account alignment when skipping multiboot2 fixed part (suggested by Konrad Rzeszutek Wilk), - create modules data if modules count != 0 (suggested by Jan Beulich), - improve macros (suggested by Jan Beulich), - reduce number of casts (suggested by Jan Beulich), - use const if possible (suggested by Jan Beulich), - drop static and __used__ attribute from reloc() (suggested by Jan Beulich), - remove isolated/stray __packed attribute from multiboot2_memory_map_t type definition (suggested by Jan Beulich), - reformat xen/include/xen/multiboot2.h (suggested by Konrad Rzeszutek Wilk), - improve comments (suggested by Konrad Rzeszutek Wilk), - remove hard tabs (suggested by Jan Beulich and Konrad Rzeszutek Wilk). v2 - suggestions/fixes: - generate multiboot2 header using macros (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich), - simplify assembly in xen/arch/x86/boot/head.S (suggested by Jan Beulich), - do not include include/xen/compiler.h in xen/arch/x86/boot/reloc.c (suggested by Jan Beulich), - do not read data beyond the end of multiboot2 information (suggested by Jan Beulich). v2 - not fixed yet: - dynamic dependency generation for xen/arch/x86/boot/reloc.S; this requires more work; I am not sure that it pays because potential patch requires more changes than addition of just multiboot2.h to Makefile (suggested by Jan Beulich), - isolated/stray __packed attribute usage for multiboot2_memory_map_t (suggested by Jan Beulich). --- xen/arch/x86/boot/Makefile|3 +- xen/arch/x86/boot/head.S | 107 ++- xen/arch/x86/boot/reloc.c | 154 +++-- xen/arch/x86/x86_64/asm-offsets.c |9 ++ xen/include/xen/multiboot2.h | 169 + 5 files changed, 432 ins
[Xen-devel] [PATCH v16 9/9] x86: add multiboot2 protocol support for relocatable images
Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
v12 - suggestions/fixes:
- replace TABs with spaces in xen/include/xen/multiboot2.h
(suggested by Doug Goldstein).
v9 - suggestions/fixes:
- use .L labels instead of numeric ones in multiboot2 data scanning loop
(suggested by Jan Beulich).
v4 - suggestions/fixes:
- do not get Xen image load base address from
multiboot2 information in x86_64 code
(suggested by Jan Beulich),
- improve label names
(suggested by Jan Beulich),
- improve comments,
(suggested by Jan Beulich).
v3 - suggestions/fixes:
- use %esi and %r15d instead of %ebp to store
Xen image load base address,
- rename some types and constants,
- reformat xen/include/xen/multiboot2.h
(suggested by Konrad Rzeszutek Wilk),
- improve comments,
- improve commit message
(suggested by Konrad Rzeszutek Wilk).
---
xen/arch/x86/boot/head.S | 16
xen/arch/x86/x86_64/asm-offsets.c |1 +
xen/include/xen/multiboot2.h | 13 +
3 files changed, 30 insertions(+)
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index dba336d..14c18d4 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -81,6 +81,13 @@ multiboot2_header_start:
/* Align modules at page boundry. */
mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED)
+/* Load address preference. */
+mb2ht_init MB2_HT(RELOCATABLE), MB2_HT(OPTIONAL), \
+ sym_offs(start), /* Min load address. */ \
+ 0x, /* The end of image max load address (4 GiB -
1). */ \
+ 0x20, /* Load address alignment (2 MiB). */ \
+ MULTIBOOT2_LOAD_PREFERENCE_HIGH
+
/* Console flags tag. */
mb2ht_init MB2_HT(CONSOLE_FLAGS), MB2_HT(OPTIONAL), \
MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
@@ -403,6 +410,15 @@ __start:
cmp %edi,MB2_fixed_total_size(%ebx)
jbe trampoline_bios_setup
+/* Get Xen image load base address from Multiboot2 information. */
+cmpl$MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR,MB2_tag_type(%ecx)
+jne .Lmb2_mem_lower
+
+mov MB2_load_base_addr(%ecx),%esi
+sub $XEN_IMG_OFFSET,%esi
+jmp .Lmb2_next_tag
+
+.Lmb2_mem_lower:
/* Get mem_lower from Multiboot2 information. */
cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,MB2_tag_type(%ecx)
cmove MB2_mem_lower(%ecx),%edx
diff --git a/xen/arch/x86/x86_64/asm-offsets.c
b/xen/arch/x86/x86_64/asm-offsets.c
index 836fed3..e136af6 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -173,6 +173,7 @@ void __dummy__(void)
OFFSET(MB2_fixed_total_size, multiboot2_fixed_t, total_size);
OFFSET(MB2_tag_type, multiboot2_tag_t, type);
OFFSET(MB2_tag_size, multiboot2_tag_t, size);
+OFFSET(MB2_load_base_addr, multiboot2_tag_load_base_addr_t,
load_base_addr);
OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
OFFSET(MB2_efi64_st, multiboot2_tag_efi64_t, pointer);
OFFSET(MB2_efi64_ih, multiboot2_tag_efi64_ih_t, pointer);
diff --git a/xen/include/xen/multiboot2.h b/xen/include/xen/multiboot2.h
index a3e3119..5acd225 100644
--- a/xen/include/xen/multiboot2.h
+++ b/xen/include/xen/multiboot2.h
@@ -59,11 +59,17 @@
#define MULTIBOOT2_HEADER_TAG_EFI_BS7
#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI32 8
#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64 9
+#define MULTIBOOT2_HEADER_TAG_RELOCATABLE 10
/* Header tag flags. */
#define MULTIBOOT2_HEADER_TAG_REQUIRED 0
#define MULTIBOOT2_HEADER_TAG_OPTIONAL 1
+/* Where image should be loaded (suggestion not requirement). */
+#define MULTIBOOT2_LOAD_PREFERENCE_NONE 0
+#define MULTIBOOT2_LOAD_PREFERENCE_LOW 1
+#define MULTIBOOT2_LOAD_PREFERENCE_HIGH 2
+
/* Header console tag console_flags. */
#define MULTIBOOT2_CONSOLE_FLAGS_CONSOLE_REQUIRED 1
#define MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED 2
@@ -90,6 +96,7 @@
#define MULTIBOOT2_TAG_TYPE_EFI_BS 18
#define MULTIBOOT2_TAG_TYPE_EFI32_IH19
#define MULTIBOOT2_TAG_TYPE_EFI64_IH20
+#define MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR 21
/* Multiboot 2 tag alignment. */
#define MULTIBOOT2_TAG_ALIGN8
@@ -120,6 +127,12 @@ typedef struct {
typedef struct {
u32 type;
u32 size;
+u32 load_base_addr;
+} multiboot2_tag_loa
[Xen-devel] [PATCH v16 3/9] efi: create new early memory allocator
There is a problem with place_string() which is used as early memory allocator. It gets memory chunks starting from start symbol and goes down. Sadly this does not work when Xen is loaded using multiboot2 protocol because then the start lives on 1 MiB address and we should not allocate a memory from below of it. So, I tried to use mem_lower address calculated by GRUB2. However, this solution works only on some machines. There are machines in the wild (e.g. Dell PowerEdge R820) which uses first ~640 KiB for boot services code or data... :-((( Hence, we need new memory allocator for Xen EFI boot code which is quite simple and generic and could be used by place_string() and efi_arch_allocate_mmap_buffer(). I think about following solutions: 1) We could use native EFI allocation functions (e.g. AllocatePool() or AllocatePages()) to get memory chunk. However, later (somewhere in __start_xen()) we must copy its contents to safe place or reserve it in e820 memory map and map it in Xen virtual address space. This means that the code referring to Xen command line, loaded modules and EFI memory map, mostly in __start_xen(), will be further complicated and diverge from legacy BIOS cases. Additionally, both former things have to be placed below 4 GiB because their addresses are stored in multiboot_info_t structure which has 32-bit relevant members. 2) We may allocate memory area statically somewhere in Xen code which could be used as memory pool for early dynamic allocations. Looks quite simple. Additionally, it would not depend on EFI at all and could be used on legacy BIOS platforms if we need it. However, we must carefully choose size of this pool. We do not want increase Xen binary size too much and waste too much memory but also we must fit at least memory map on x86 EFI platforms. As I saw on small machine, e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more than 200 entries. Every entry on x86-64 platform is 40 bytes in size. So, it means that we need more than 8 KiB for EFI memory map only. Additionally, if we use this memory pool for Xen and modules command line storage (it would be used when xen.efi is executed as EFI application) then we should add, I think, about 1 KiB. In this case, to be on safe side, we should assume at least 64 KiB pool for early memory allocations. Which is about 4 times of our earlier calculations. However, during discussion on Xen-devel Jan Beulich suggested that just in case we should use 1 MiB memory pool like it is in original place_string() implementation. So, let's use 1 MiB as it was proposed. If we think that we should not waste unallocated memory in the pool on running system then we can mark this region as __initdata and move all required data to dynamically allocated places somewhere in __start_xen(). 2a) We could put memory pool into .bss.page_aligned section. Then allocate memory chunks starting from the lowest address. After init phase we can free unused portion of the memory pool as in case of .init.text or .init.data sections. This way we do not need to allocate any space in image file and freeing of unused area in the memory pool is very simple. Now #2a solution is implemented because it is quite simple and requires limited number of changes, especially in __start_xen(). New allocator is quite generic and can be used on ARM platforms too. Though it is not enabled on ARM yet due to lack of some prereq. List of them is placed before ebmalloc code. Signed-off-by: Daniel Kiper Acked-by: Jan Beulich Acked-by: Julien Grall Reviewed-by: Doug Goldstein Tested-by: Doug Goldstein --- v11 - suggestions/fixes: - #ifdef only EBMALLOC_SIZE from ebmalloc machinery (suggested by Jan Beulich). v10 - suggestions/fixes: - remove unneeded ARM free_ebmalloc_unused_mem() stub. v9 - suggestions/fixes: - call free_ebmalloc_unused_mem() from efi_init_memory() instead of xen/arch/arm/setup.c:init_done() (suggested by Jan Beulich), - improve comments. v8 - suggestions/fixes: - disable whole ebmalloc machinery on ARM platforms, - add comment saying what should be done before enabling ebmalloc on ARM, (suggested by Julien Grall), - move ebmalloc code before efi-boot.h inclusion and remove unneeded forward declaration (suggested by Jan Beulich), - remove free_ebmalloc_unused_mem() call from xen/arch/arm/setup.c:init_done() (suggested by Julien Grall), - improve commit message. v7 - suggestions/fixes: - enable most of ebmalloc machinery on ARM platforms (suggested by Jan Beulich), - remove unneeded cast (suggested by Jan Beulich), - wrap long line (suggested by Jan Beulich), - improve commit message. v6 - suggestions/fixes: - optimize ebmalloc allocator, - move ebmalloc machinery to xen/common/efi/boot.c (suggested by Jan Beulich), - enforce PAGE_SIZE
[Xen-devel] [PATCH v16 6/9] x86/setup: use XEN_IMG_OFFSET instead of...
..calculating its value during runtime. Signed-off-by: Daniel Kiper Acked-by: Jan Beulich Reviewed-by: Doug Goldstein --- xen/arch/x86/setup.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index e2a5f76..8feed35 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -942,7 +942,6 @@ void __init noreturn __start_xen(unsigned long mbi_p) l4_pgentry_t *pl4e; l3_pgentry_t *pl3e; l2_pgentry_t *pl2e; -uint64_t load_start; int i, j, k; /* Select relocation address. */ @@ -956,9 +955,8 @@ void __init noreturn __start_xen(unsigned long mbi_p) * with a barrier(). After this we must *not* modify static/global * data until after we have switched to the relocated pagetables! */ -load_start = (unsigned long)_start - XEN_VIRT_START; barrier(); -move_memory(e + load_start, load_start, _end - _start, 1); +move_memory(e + XEN_IMG_OFFSET, XEN_IMG_OFFSET, _end - _start, 1); /* Walk initial pagetables, relocating page directory entries. */ pl4e = __va(__pa(idle_pg_table)); -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v16 4/9] x86: add multiboot2 protocol support for EFI platforms
This way Xen can be loaded on EFI platforms using GRUB2 and other boot loaders which support multiboot2 protocol. Signed-off-by: Daniel Kiper --- v16 - suggestions/fixes: - improve comments in error handling (suggested by Jan Beulich). v15 - suggestions/fixes: - rearrange inline assembly arguments in xen/arch/x86/efi/stub.c:efi_multiboot2() (suggested by Jan Beulich), - improve comments in error handling in legacy BIOS Multiboot2 scanning loop (suggested by Jan Beulich). v14 - suggestions/fixes: - mark .init.data section as writable; by the way we must change similar definition in xen/arch/x86/boot/x86_64.S because otherwise compiler complains about section types conflicts (suggested by Jan Beulich), - use %r15 instead of %r15d (suggested by Jan Beulich), - remove redundant add from UEFI stack alignment (suggested by Jan Beulich), - use "mov (%rsp),%rdi" instead of "pop %rdi/push %rdi" (suggested by Jan Beulich), - return void instead of paddr_t from efi_multiboot2() and then simplify a bit trampoline setup assembly (suggested by Jan Beulich), - remove "(XEN)" from efi_multiboot2() stub error messages (suggested by Jan Beulich), - move err from inline assembly OutputOperands to InputOperands in stub.c:efi_multiboot2(); this way we avoid following compile time error: stub.c: In function ‘efi_multiboot2’: stub.c:36:5: error: read-only variable ‘err’ used as ‘asm’ output asm volatile( ^~~ issue was introduced by changing err type to "static const CHAR16 __initconst"; potentially we can revert this change but move to InputOperands looks better IMO; even if we are not able to specify %rdx in Clobbers; simply we do not care because next instruction after call is hlt (discovered by Konrad Rzeszutek Wilk and Marcos Matsunaga), - take into account MBI_SPACE_MIN in ASSERT((trampoline_end - trampoline_start) < ...) (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich). v13 - suggestions/fixes: - move vga_text_buffer and efi_platform to .init.data section (suggested by Jan Beulich), - reduce number of error branches in EFI code in xen/arch/x86/boot/head.S (suggested by Jan Beulich), - rename run_bs label to .Lrun_bs (suggested by Jan Beulich), - align the stack as UEFI spec requires (suggested by Jan Beulich), - change trampoline region memory layout (suggested by Jan Beulich), - revert changes in efi_arch_pre_exit_boot() (suggested by Jan Beulich), - relocate_trampoline() must set trampoline_phys for all bootloaders; otherwise fallback allocator is always used if Xen was loaded with Multiboot2 protocol, - change err type in efi_multiboot2() to "static const CHAR16 __initconst" (suggested by Jan Beulich), - change asm "g" constraint to "rm" in efi_multiboot2() (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich and Doug Goldstein). v12 - suggestions/fixes: - rename __efi64_start to __efi64_mb2_start (suggested by Andrew Cooper), - use efi_arch_memory_setup() machinery as trampoline et consortes main memory allocator (suggested by Doug Goldstein), - allocate space for mbi struct in efi_arch_memory_setup() too; this thing was not taken into account in earlier releases, - revert trampoline et consortes fallback memory allocator code in efi_arch_process_memory_map() to current upstream state (suggested by Doug Goldstein), - further simplify efi_arch_pre_exit_boot() code, - call efi_arch_memory_setup() from efi_multiboot2() (suggested by Doug Goldstein), - fix asembly call argument in xen/arch/x86/efi/stub.c (suggested by Andrew Cooper), - add ASSERT() for trampoline size (suggested by Doug Goldstein), - add KB() macro (suggested by Doug Goldstein), - improve comments (suggested by Andrew Cooper and Doug Goldstein). v10 - suggestions/fixes: - replace ljmpl with lretq (suggested by Andrew Cooper), - introduce efi_platform to increase code readability (suggested by Andrew Cooper). v9 - suggestions/fixes: - use .L labels instead of numeric ones in multiboot2 data scanning loops (suggested by Jan Beulich). v8 - suggestions/fixes: - use __bss_start(%rip)/__bss_end(%rip) instead of of .startof.(.bss)(%rip)/$.sizeof.(.bss) because latter is not tested extensively in different built environments yet (suggested by Andrew Cooper), - fix multiboot2 data scanning loop in x86_32 code (suggested by Jan Beulich), - add check for extra mem for mbi data if Xen is loaded via multiboot2 protocol on EFI platform (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich). v7 - su
[Xen-devel] [PATCH v16 5/9] x86: change default load address from 1 MiB to 2 MiB
Subsequent patches introducing relocatable early boot code play with
page tables using 2 MiB huge pages. If load address is not aligned at
2 MiB then code touching such page tables must have special cases for
start and end of Xen image memory region. So, let's make life easier
and move default load address from 1 MiB to 2 MiB. This way page table
code will be nice and easy. Hence, there is a chance that it will be
less error prone too... :-)))
Additionally, drop first 2 MiB mapping from Xen image mapping.
It is no longer needed.
Signed-off-by: Daniel Kiper
Reviewed-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
v8 - suggestions/fixes:
- drop first 2 MiB mapping from Xen image mapping
(suggested by Jan Beulich),
- improve commit message.
v7 - suggestions/fixes:
- minor cleanups
(suggested by Jan Beulich).
---
xen/arch/x86/Makefile |2 +-
xen/arch/x86/Rules.mk |3 +++
xen/arch/x86/boot/head.S |8
xen/arch/x86/boot/x86_64.S |5 +++--
xen/arch/x86/setup.c |3 ++-
xen/arch/x86/xen.lds.S |2 +-
6 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index d6980b5..fead99a 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -91,7 +91,7 @@ all_symbols =
endif
$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
- ./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET) 0x10 \
+ ./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET)
$(XEN_IMG_OFFSET) \
`$(NM) $(TARGET)-syms | sed -ne 's/^\([^ ]*\) .
__2M_rwdata_end$$/0x\1/p'`
ALL_OBJS := $(BASEDIR)/arch/x86/boot/built_in.o
$(BASEDIR)/arch/x86/efi/built_in.o $(ALL_OBJS)
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 72be8b2..568657e 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -1,9 +1,12 @@
# x86-specific definitions
+XEN_IMG_OFFSET := 0x20
+
CFLAGS += -I$(BASEDIR)/include
CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
+CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFFSET)
CFLAGS += '-D__OBJECT_LABEL__=$(subst /,$$,$(subst -,_,$(subst
$(BASEDIR)/,,$(CURDIR))/$@))'
# Prevent floating-point variables from creeping into Xen.
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index a2177c3..b5d9ec8 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -524,14 +524,6 @@ trampoline_setup:
mov %eax,sym_phys(boot_tsc_stamp)
mov %edx,sym_phys(boot_tsc_stamp+4)
-/*
- * During boot, hook 4kB mappings of first 2MB of memory into L2.
- * This avoids mixing cachability for the legacy VGA region, and is
- * corrected when Xen relocates itself.
- */
-mov $sym_phys(l1_identmap)+__PAGE_HYPERVISOR,%edi
-mov %edi,sym_phys(l2_xenmap)
-
/* Apply relocations to bootstrap trampoline. */
mov sym_phys(trampoline_phys),%edx
mov $sym_phys(__trampoline_rel_start),%edi
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index 4d507fb..f9d1022 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -121,8 +121,9 @@ GLOBAL(l2_identmap)
* page.
*/
GLOBAL(l2_xenmap)
-idx = 0
-.rept 8
+.quad 0
+idx = 1
+.rept 7
.quad sym_phys(__image_base__) + (idx << L2_PAGETABLE_SHIFT) +
(PAGE_HYPERVISOR | _PAGE_PSE)
idx = idx + 1
.endr
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 66b7aba..e2a5f76 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -998,7 +998,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
* Undo the temporary-hooking of the l1_identmap. __2M_text_start
* is contained in this PTE.
*/
-BUG_ON(l2_table_offset((unsigned long)_erodata) ==
+BUG_ON(using_2M_mapping() &&
+ l2_table_offset((unsigned long)_erodata) ==
l2_table_offset((unsigned long)_stext));
*pl2e++ = l2e_from_pfn(xen_phys_start >> PAGE_SHIFT,
PAGE_HYPERVISOR_RX | _PAGE_PSE);
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 066aca6..ff93a0b 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -54,7 +54,7 @@ SECTIONS
__2M_text_start = .; /* Start of 2M superpages, mapped RX. */
#endif
- . = __XEN_VIRT_START + MB(1);
+ . = __XEN_VIRT_START + XEN_IMG_OFFSET;
_start = .;
.text : {
_stext = .;/* Text and read-only data */
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v16 0/9] x86: multiboot2 protocol support
Hi, I am sending sixteenth version of multiboot2 protocol support for legacy BIOS and EFI platforms. This patch series release contains fixes for all known/confirmed issues. The final goal is xen.efi binary file which could be loaded by EFI loader, multiboot (v1) protocol (only on legacy BIOS platforms) and multiboot2 protocol. This way we will have: - smaller Xen code base, - one code base for xen.gz and xen.efi, - one build method for xen.gz and xen.efi; xen.efi will be extracted from xen(-syms) file using objcopy or special custom tool, - xen.efi build will not so strongly depend on a given GCC and binutils version. Here is short list of changes since v15: - changed patch: 4. If you are not interested in this patch series at all please drop me a line and I will remove you from distribution list. Daniel xen/arch/x86/Makefile |4 +- xen/arch/x86/Rules.mk |3 + xen/arch/x86/boot/Makefile|3 +- xen/arch/x86/boot/head.S | 584 ++ xen/arch/x86/boot/reloc.c | 154 +- xen/arch/x86/boot/trampoline.S|7 +- xen/arch/x86/boot/wakeup.S|4 +- xen/arch/x86/boot/x86_64.S| 44 +++ xen/arch/x86/efi/Makefile | 14 +- xen/arch/x86/efi/efi-boot.h | 60 +++-- xen/arch/x86/efi/stub.c | 39 ++ xen/arch/x86/setup.c | 24 ++-- xen/arch/x86/x86_64/asm-offsets.c | 15 +++ xen/arch/x86/xen.lds.S| 13 +- xen/common/efi/boot.c | 64 + xen/common/efi/runtime.c |9 ++ xen/include/asm-x86/config.h |5 + xen/include/asm-x86/page.h|2 +- xen/include/xen/config.h |1 + xen/include/xen/multiboot2.h | 182 ++ 20 files changed, 1108 insertions(+), 123 deletions(-) Daniel Kiper (9): x86: add multiboot2 protocol support efi: build xen.gz with EFI code efi: create new early memory allocator x86: add multiboot2 protocol support for EFI platforms x86: change default load address from 1 MiB to 2 MiB x86/setup: use XEN_IMG_OFFSET instead of... x86: make Xen early boot code relocatable x86/boot: rename sym_phys() to sym_offs() x86: add multiboot2 protocol support for relocatable images ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v16 2/9] efi: build xen.gz with EFI code
Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.
If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file contains
many sections which are not "linear" (one after another without any holes)
or even do not have representation in a file (e.g. BSS). From EFI point
of view everything is OK and works. However, this file layout cannot be
properly interpreted by multiboot protocols family. In theory there is
a chance that we could build proper PE file (from multiboot protocols POV)
using current build system. However, it means that xen.efi further diverge
from Xen ELF file (in terms of contents and build method). On the other
hand ELF has all needed properties. So, it means that this is good starting
point for further development. Additionally, I think that this is also good
starting point for further xen.efi code and build optimizations. It looks
that there is a chance that finally we can generate xen.efi directly from
Xen ELF using just simple objcopy or other tool. This way we will have one
Xen binary which can be loaded by three boot protocols: EFI native loader,
multiboot (v1) and multiboot2.
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
v14 - suggestions/fixes:
- at least GNU Make 4.1 does not build efi/buildid.o if nothing
depends on it; so, add "boot.init.o: buildid.o" dependency to
force efi/buildid.o on some versions of make; I hope that this
small change does not invalidate Acked-by/Reviewed-by; however,
I am dropping Tested-by
(discovered by Konrad Rzeszutek Wilk and Marcos Matsunaga).
v6 - suggestions/fixes:
- improve efi_enabled() checks in efi_runtime_call()
(suggested by Jan Beulich).
v5 - suggestions/fixes:
- properly calculate efi symbol address in
xen/arch/x86/xen.lds.S (I hope that this
change does not invalidate Jan's ACK).
v4 - suggestions/fixes:
- functions should return -ENOSYS instead
of -EOPNOTSUPP if EFI runtime services
are not available
(suggested by Jan Beulich),
- remove stale bits from xen/arch/x86/Makefile
(suggested by Jan Beulich).
v3 - suggestions/fixes:
- check for EFI platform in EFI code
(suggested by Jan Beulich),
- fix Makefiles
(suggested by Jan Beulich),
- improve commit message
(suggested by Jan Beulich).
v2 - suggestions/fixes:
- build EFI code only if it is supported in a given build environment
(suggested by Jan Beulich).
---
xen/arch/x86/Makefile |2 +-
xen/arch/x86/efi/Makefile | 14 ++
xen/arch/x86/xen.lds.S|4 ++--
xen/common/efi/boot.c |3 +++
xen/common/efi/runtime.c |9 +
5 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 10f519e..d6980b5 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -220,6 +220,6 @@ efi/mkreloc: efi/mkreloc.c
clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
- rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/.*.d efi/*.efi
efi/disabled efi/mkreloc
+ rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/disabled efi/mkreloc
rm -f boot/cmdline.S boot/reloc.S boot/*.lnk boot/*.bin
rm -f note.o
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index ad3fdf7..3edff1c 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,18 +1,16 @@
CFLAGS += -fshort-wchar
-obj-y += stub.o
-
-create = test -e $(1) || touch -t 19990101 $(1)
-
efi := y$(shell rm -f disabled)
efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c
check.c 2>disabled && echo y))
efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o
2>disabled && echo y))
-efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o);
$(call create,runtime.o)))
-
-extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o buildid.o
+efi := $(if $(efi),$(shell rm disabled)y)
%.o: %.ihex
$(OBJCOPY) -I ihex -O binary $< $@
-stub.o: $(extra-y)
+boot.init.o: buildid.o
+
+obj-y := stub.o
+obj-$(efi) := boot.init.o compat.o relocs-dummy.o runtime.o
+extra-$(efi) += buildid.o
nogcov-$(efi) += stub.o
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 3368086..4f06da1 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -269,10 +269,10 @@ SECTIONS
.pad : {
. = ALIGN(MB(16));
} :text
-#else
- efi = .;
#endif
+ efi = DEFINED(efi) ? efi : .;
+
/* Sections to be discarded */
/DISCARD/ : {
*(.exit.text)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 3e5e4ab..df8c702 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -125
[Xen-devel] VM Live Migration with Local Storage
Hello, I have been to doing some research and as far as I know XEN supports Live Migration of VMs that only have shared storage. (i.e. iSCSI) If the VM has been booted with local storage it cannot be live migrated. QEMU seems to support live migration with local storage (I have tested using 'virsh migrate with the '--storage-copy-all' option) I am wondering if this still true in the latest XEN release. Are there plans to add this functionality in future releases? I would be interested in contributing to the Xen Project by adding this functionality. Thanks, Bruno ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: introduce vwfi parameter
On Tue, 21 Feb 2017, Julien Grall wrote: > Hi Stefano, > > On 21/02/17 17:49, Stefano Stabellini wrote: > > On Tue, 21 Feb 2017, Dario Faggioli wrote: > > > On Tue, 2017-02-21 at 13:46 +, George Dunlap wrote: > > > Oh, actually, if --which I only now realize may be what you are > > > referring to, since you're talking about "guest burning its credits"-- > > > you let the vCPU put the pCPU to sleep *but*, when it wakes up (or when > > > the scheduler runs again for whatever reason), you charge to it for all > > > the time the the pCPU was actually idle/sleeping, well, that may > > > actually not break scheduling, or cause disruption to the service of > > > other vCPUs But indeed I'd consider it rather counter intuitive a > > > behavior. > > > > How can this be safe? There could be no interrupts programmed to wake up > > the pcpu at all. In fact, I don't think today there would be any, unless > > we set one up in Xen for the specific purpose of interrupting the pcpu > > sleep. > > > > I don't know the inner working of the scheduler, but does it always send > > an interrupt to other pcpu to schedule something? > > You still seem to assume that WFI/WFE is the only way to get a vCPU > unscheduled. If that was the case it would be utterly wrong because you cannot > expect a guest to use them. > > > > > What if there are 2 vcpu pinned to the same pcpu? This cannot be fair. > > Why wouldn't it be fair? This is the same situation as a guest vCPU not using > WFI/WFE. I read your suggestion as trapping WFI in Xen, then, depending on settings, executing WFI in the Xen trap handler to idle the pcpu. That doesn't work. But I take you suggested not trapping wfi (remove HCR_TWI), executing the instruction in guest context. That is what we used to do in the early days (before a780f750). It should be safe and possibly even quick. I'll rerun the numbers and let you know. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: introduce vwfi parameter
Hi Stefano, On 21/02/17 18:03, Stefano Stabellini wrote: On Tue, 21 Feb 2017, Julien Grall wrote: Hi George, On 21/02/17 13:46, George Dunlap wrote: I think our options look like: Thank you for the summary of the options! A. Don't trap guest WFI at all -- allow it to 'halt' in moderate-power-but-ready-for-interrupt mode. B. Trap guest WFI and block normally. C. Trap guest WFI and poll instead of idling. D. Trap guest WFI and take that as a hint to "idle" in a non-deep sleep state (perhaps, for instance, using the WFI instruction). A is safe because the scheduler should already have set a timer to break out of it if necessary. The only potential issue here is that the guest is burning its credits, meaning that other vcpus with something potentially useful to do aren't being allowed to run; and then later when this vcpu has something useful to do it may be prevented from running because of low credits. (This may be what Dario means when he says it "breaks scheduling"). B, C, and D have the advantage that the guest will not be charged for credits, and other useful work can be done if it's possible. B and C have the disadvantage that the effect will be significantly different under Xen than on real hardware: B will mean it will go into a deep sleep state (and thus not be as responsive as on real hardare); C has the disadvantage that there won't be any significant power savings. I'd like to correct one misunderstanding here. Today the idle_loop on ARM is doing a WFI. This is not a deep-sleep state, it is fairly quite quick to come back. What really cost if the context switch of the state of the vCPU during blocking. So I think B and D are the same. Or did you expect D to not switch to the idle vCPU? I think that B and D are the same only in the scenario where each vcpu is pinned to a different pcpu. However, we cannot automatically configure this scenario and we cannot detect it when it happens. Again, there is no deep sleep state supported on Xen today. The idle loop on Xen is a simple WFI. So there is *no* difference between B and D no matter the configuration, both option trap WFI and block the vCPU. Discussions on how to make this specific scenario better are fruitless until we can detect and configure Xen for it. Your suggestion to do a real wfi when the guest issues a virtual wfi is a good improvement at that point in time. Now, we cannot do it, because we don't know when it happens. If Dario and George come up with a way to detect it or configure it, I volunteer to write the wfi patch for Xen ARM. Until then, we can only decide if it is worth having a vwfi option, either system wide or per domain, to change vwfi behavior from sleep to poll. When we have a way to configure 1vcpu=1pcpu, we'll be able to add one more option, for example vwfi=passthrough, that will allow a vcpu to perform a physical wfi, leading to optimal power saving and wake up times. Please read my answer to Dario (<14575011-0042-8940-c19f-2482136ff...@foss.arm.com>) regarding why an baremetal app will use WFI and what are the expectations of WFI. I will summarize my e-mail with that: My shiny baremetal app is running nicely without virtualization, good power usage, good interrupt latency. Now, I want to use virtualization to abstract the hardware, it will have a small overhead impact because of virtualization but it is ok. Now, you are telling me that if I want good interrupt latency, I would have to give up on power. I would likely give up on using virtualization in this case, better to adapt my app to the newer hardware. Do you really expect user to make another decision? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: introduce vwfi parameter
On 21/02/17 17:49, Stefano Stabellini wrote: > On Tue, 21 Feb 2017, Dario Faggioli wrote: >> On Tue, 2017-02-21 at 13:46 +, George Dunlap wrote: >>> >>> A. Don't trap guest WFI at all -- allow it to 'halt' in >>> moderate-power-but-ready-for-interrupt mode. >>> >>> [..] >>> >>> A is safe because the scheduler should already have set a timer to >>> break >>> out of it if necessary. The only potential issue here is that the >>> guest >>> is burning its credits, meaning that other vcpus with something >>> potentially useful to do aren't being allowed to run; and then later >>> when this vcpu has something useful to do it may be prevented from >>> running because of low credits. (This may be what Dario means when >>> he >>> says it "breaks scheduling"). >>> >> Are you also referring to the case when there are less vCPUs around >> than the host has pCPUs (and, ideally, all vCPUs are pinned 1:1 to a >> pCPU)? If yes, I agree that we're probably fine, but we have to check >> and enforce all this to be the case. >> >> If no, think at a situation where there is 1 vCPU running on a pCPU and >> 3 vCPUs in the runqueue (it may be a per-CPU Credit1 runqueue or a >> shared among some pCPUs Credit2 runqueue). If the running vCPU goes >> idle, let's say with WFI, we _don't_ want the pCPU to enter neither >> moderate nor deep sleep, we want to pick up the first of the 3 other >> vCPUs that are waiting in the runqueue. >> >> This is what I mean when I say "breaks scheduling". :-) > > That's right, I cannot see how this can be made to work correctly. > > >> Oh, actually, if --which I only now realize may be what you are >> referring to, since you're talking about "guest burning its credits"-- >> you let the vCPU put the pCPU to sleep *but*, when it wakes up (or when >> the scheduler runs again for whatever reason), you charge to it for all >> the time the the pCPU was actually idle/sleeping, well, that may >> actually not break scheduling, or cause disruption to the service of >> other vCPUs But indeed I'd consider it rather counter intuitive a >> behavior. > > How can this be safe? There could be no interrupts programmed to wake up > the pcpu at all. In fact, I don't think today there would be any, unless > we set one up in Xen for the specific purpose of interrupting the pcpu > sleep. > > I don't know the inner working of the scheduler, but does it always send > an interrupt to other pcpu to schedule something? Letting a guest call WFI is as safe as letting a guest `while(1);`. Xen *always* has to set a timer interrupt before switching to the guest context to make sure that it can pre-empt the vcpu -- otherwise any vcpu could perform a DoS by simply continually executing instructions. As long as the guest can't disable host interrupts, and as long as the scheduler interrupt will break out of a guest WFI into Xen, it should be safe. > What if there are 2 vcpu pinned to the same pcpu? This cannot be fair. From the scheduler's perspective, the WFI would be the same as the `while(1)`. If you had two vcpus doing while(1) on the same vcpu, the credit2 scheduler would (approximately) let one run for 2ms, then the other for 2ms, and so on, each getting 50%. If instead you have one doing a WFI, then the credit2 scheduler would do the same -- let the first one do WFI for 2ms, then preempt it and let the other one spin for 2ms, then let the first one WFI for 2ms, &c. (Obviously the exact behaviour would be significantly more random.) >> What would be the benefit of this? That we don't context switch (either >> to idle or to someone else)? > > Yes, that would be the benefit. If ARM had the equivalent of posted interrupts, then a pinned guest could efficiently wait for interrupts with no additional latency from virtualization without having to poll. (Speaking of which -- that could be an interesting optimization even on x86... if a pcpu has no vcpus waiting to run, then disable HLT exit.) -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: introduce vwfi parameter
On Tue, 21 Feb 2017, Julien Grall wrote: > Hi George, > > On 21/02/17 13:46, George Dunlap wrote: > > I think our options look like: > > Thank you for the summary of the options! > > > > > A. Don't trap guest WFI at all -- allow it to 'halt' in > > moderate-power-but-ready-for-interrupt mode. > > > > B. Trap guest WFI and block normally. > > > > C. Trap guest WFI and poll instead of idling. > > > > D. Trap guest WFI and take that as a hint to "idle" in a non-deep sleep > > state (perhaps, for instance, using the WFI instruction). > > > > A is safe because the scheduler should already have set a timer to break > > out of it if necessary. The only potential issue here is that the guest > > is burning its credits, meaning that other vcpus with something > > potentially useful to do aren't being allowed to run; and then later > > when this vcpu has something useful to do it may be prevented from > > running because of low credits. (This may be what Dario means when he > > says it "breaks scheduling"). > > > > B, C, and D have the advantage that the guest will not be charged for > > credits, and other useful work can be done if it's possible. > > > > B and C have the disadvantage that the effect will be significantly > > different under Xen than on real hardware: B will mean it will go into a > > deep sleep state (and thus not be as responsive as on real hardare); C > > has the disadvantage that there won't be any significant power savings. > > I'd like to correct one misunderstanding here. Today the idle_loop on ARM is > doing a WFI. This is not a deep-sleep state, it is fairly quite quick to come > back. What really cost if the context switch of the state of the vCPU during > blocking. > > So I think B and D are the same. Or did you expect D to not switch to the idle > vCPU? I think that B and D are the same only in the scenario where each vcpu is pinned to a different pcpu. However, we cannot automatically configure this scenario and we cannot detect it when it happens. Discussions on how to make this specific scenario better are fruitless until we can detect and configure Xen for it. Your suggestion to do a real wfi when the guest issues a virtual wfi is a good improvement at that point in time. Now, we cannot do it, because we don't know when it happens. If Dario and George come up with a way to detect it or configure it, I volunteer to write the wfi patch for Xen ARM. Until then, we can only decide if it is worth having a vwfi option, either system wide or per domain, to change vwfi behavior from sleep to poll. When we have a way to configure 1vcpu=1pcpu, we'll be able to add one more option, for example vwfi=passthrough, that will allow a vcpu to perform a physical wfi, leading to optimal power saving and wake up times. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: introduce vwfi parameter
Hi Stefano, On 21/02/17 17:49, Stefano Stabellini wrote: On Tue, 21 Feb 2017, Dario Faggioli wrote: On Tue, 2017-02-21 at 13:46 +, George Dunlap wrote: Oh, actually, if --which I only now realize may be what you are referring to, since you're talking about "guest burning its credits"-- you let the vCPU put the pCPU to sleep *but*, when it wakes up (or when the scheduler runs again for whatever reason), you charge to it for all the time the the pCPU was actually idle/sleeping, well, that may actually not break scheduling, or cause disruption to the service of other vCPUs But indeed I'd consider it rather counter intuitive a behavior. How can this be safe? There could be no interrupts programmed to wake up the pcpu at all. In fact, I don't think today there would be any, unless we set one up in Xen for the specific purpose of interrupting the pcpu sleep. I don't know the inner working of the scheduler, but does it always send an interrupt to other pcpu to schedule something? You still seem to assume that WFI/WFE is the only way to get a vCPU unscheduled. If that was the case it would be utterly wrong because you cannot expect a guest to use them. What if there are 2 vcpu pinned to the same pcpu? This cannot be fair. Why wouldn't it be fair? This is the same situation as a guest vCPU not using WFI/WFE. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: introduce vwfi parameter
On Tue, 21 Feb 2017, Dario Faggioli wrote: > On Tue, 2017-02-21 at 13:46 +, George Dunlap wrote: > > > > A. Don't trap guest WFI at all -- allow it to 'halt' in > > moderate-power-but-ready-for-interrupt mode. > > > > [..] > > > > A is safe because the scheduler should already have set a timer to > > break > > out of it if necessary. The only potential issue here is that the > > guest > > is burning its credits, meaning that other vcpus with something > > potentially useful to do aren't being allowed to run; and then later > > when this vcpu has something useful to do it may be prevented from > > running because of low credits. (This may be what Dario means when > > he > > says it "breaks scheduling"). > > > Are you also referring to the case when there are less vCPUs around > than the host has pCPUs (and, ideally, all vCPUs are pinned 1:1 to a > pCPU)? If yes, I agree that we're probably fine, but we have to check > and enforce all this to be the case. > > If no, think at a situation where there is 1 vCPU running on a pCPU and > 3 vCPUs in the runqueue (it may be a per-CPU Credit1 runqueue or a > shared among some pCPUs Credit2 runqueue). If the running vCPU goes > idle, let's say with WFI, we _don't_ want the pCPU to enter neither > moderate nor deep sleep, we want to pick up the first of the 3 other > vCPUs that are waiting in the runqueue. > > This is what I mean when I say "breaks scheduling". :-) That's right, I cannot see how this can be made to work correctly. > Oh, actually, if --which I only now realize may be what you are > referring to, since you're talking about "guest burning its credits"-- > you let the vCPU put the pCPU to sleep *but*, when it wakes up (or when > the scheduler runs again for whatever reason), you charge to it for all > the time the the pCPU was actually idle/sleeping, well, that may > actually not break scheduling, or cause disruption to the service of > other vCPUs But indeed I'd consider it rather counter intuitive a > behavior. How can this be safe? There could be no interrupts programmed to wake up the pcpu at all. In fact, I don't think today there would be any, unless we set one up in Xen for the specific purpose of interrupting the pcpu sleep. I don't know the inner working of the scheduler, but does it always send an interrupt to other pcpu to schedule something? What if there are 2 vcpu pinned to the same pcpu? This cannot be fair. Obviously this behavior cannot be the default. But even if we introduce it as a command line option, when the user enables it can cause the whole system to hang if she is not careful. Isn't that right? We have no way to detect when we can do this safely. I prefer an option such as vwfi=pool, where in the worst case the user burns more power but there are no unexpected hangs. > In fact, it'd mean that the guest has issued WFI because he wanted to > sleep and we do put it to sleep. But when it wakes up, we treat it like > it had busy waited. > > What would be the benefit of this? That we don't context switch (either > to idle or to someone else)? Yes, that would be the benefit.___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 06/10] x86/cpuid: Handle leaf 0x6 in guest_cpuid()
On 21/02/17 17:40, Andrew Cooper wrote: > On 21/02/17 17:25, Jan Beulich wrote: > On 20.02.17 at 12:00, wrote: >>> The thermal/performance leaf was previously hidden from HVM guests, but >>> fully >>> visible to PV guests. Most of the leaf refers to MSR availability, and >>> there >>> is nothing an unprivileged PV guest can do with the information, so hide the >>> leaf entirely. >>> >>> The PV MSR handling logic as minimal support for some thermal/perf >>> operations >> ... has ... >> >>> from the hardware domain, so leak through the implemented subset of >>> features. >> Does it make sense to continue to special case PV hwdom here? > Being able to play with these MSRs will be actively wrong for HVM > context. It is already fairly wrong for PV context, as nothing prevents > you being rescheduled across pcpus while in the middle of a read/write > cycle on the MSRs. > >> Should there perhaps be at least a fixme note? > One way or another, we have to invest some different mechanism of > providing real hardware details to the hardware domain which don't > collide with their vcpus. s/invest/invent/. Sorry for the confusion. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 02/10] x86/gen-cpuid: Clarify the intended meaning of AVX wrt feature dependencies
On 21/02/17 17:17, Jan Beulich wrote:
On 21.02.17 at 18:12, wrote:
>> Which particular feature groups? I could extend that text to say
>>
>> "VEX/XOP-encoded GPR instructions, such as those from the BMI{1,2} and
>> $X sets..."
> TBM and LWP.
Ok. Final text reads:
# AVX is not taken to mean support for the VEX prefix itself (nor XOP
# for the XOP prefix). VEX/XOP-encoded GPR instructions, such as
# those from the BMI{1,2}, TBM and LWP sets function fine in the
# absence of any enabled xstate.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 06/10] x86/cpuid: Handle leaf 0x6 in guest_cpuid()
On 21/02/17 17:25, Jan Beulich wrote: On 20.02.17 at 12:00, wrote: >> The thermal/performance leaf was previously hidden from HVM guests, but fully >> visible to PV guests. Most of the leaf refers to MSR availability, and there >> is nothing an unprivileged PV guest can do with the information, so hide the >> leaf entirely. >> >> The PV MSR handling logic as minimal support for some thermal/perf operations > ... has ... > >> from the hardware domain, so leak through the implemented subset of >> features. > Does it make sense to continue to special case PV hwdom here? Being able to play with these MSRs will be actively wrong for HVM context. It is already fairly wrong for PV context, as nothing prevents you being rescheduled across pcpus while in the middle of a read/write cycle on the MSRs. > Should there perhaps be at least a fixme note? One way or another, we have to invest some different mechanism of providing real hardware details to the hardware domain which don't collide with their vcpus. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: introduce vwfi parameter
On Tue, 21 Feb 2017, Dario Faggioli wrote: > On Tue, 2017-02-21 at 12:30 +, Julien Grall wrote: > > On 21/02/2017 09:09, Dario Faggioli wrote: > > > Well, TBH, we still are not entirely sure who the culprit is for > > > high > > > latency. There are spikes in Credit2, and I'm investigating that. > > > But > > > apart from them? I think we need other numbers with which we can > > > compare the numbers that Stefano has collected. > > > > I think the problem is because we save/restore the vCPU state when > > switching to the idle vCPU. > > > That may well be. Or at least, that may well be part of the problem. I > don't know enough of ARM to know whether it's the predominant cause of > high latencies or not. > > On x86, on Linux, polling is used to prevent the CPU to go in deep > C-states. I was assuming things to be similar on ARM, and that's the > reason why I thought introducing a polling mode could have been useful > (although wasteful). > > But you guys are the ones that know whether or not that is the case > (and in another email, you seem to say it's not). The total cost of context switching is about 1100ns, which is significant. The remaining 1300ns difference between vwfi=sleep and vwfi=idle is due to sched_op(wait) and sched_op(schedule). As I mentioned, I have a patch to zero the context switch time when we can back and force between a regular vcpu and the idle vcpu, but it's a complex ugly patch I don't know if we want to maintain. > > Let say the only 1 vCPU can run on the pCPU, when the vCPU is issuing > > a > > WFI the following steps will happen: > > * WFI trapped and vcpu blocked > > * save vCPU state > > * run idle_loop > > -> Interrupt incoming for the guest > > * restore vCPU state > > * back to the guest > > > > Saving/restoring on ARM requires to context switch all the state of > > the > > VM (this is not saved in memory when entering in the hypervisor). > > This > > include things like system register, interrupt controller state, > > FPU... > > > Yes. In fact, on x86, we have what we call 'lazy context switch', which > deals specifically with some aspect of this situation. > > Indeed it seems like implementing the same on ARM --if you don't have > it already, and if possible-- would be useful in this case too. This sounds like what I have.___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 04/10] x86/cpuid: Handle leaf 0x4 in guest_cpuid()
On 21/02/17 17:16, Jan Beulich wrote:
On 20.02.17 at 12:00, wrote:
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -163,6 +163,9 @@ static void recalculate_xstate(struct cpuid_policy *p)
>> */
>> static void recalculate_misc(struct cpuid_policy *p)
>> {
>> +/* Leaves with subleaf unions. */
>> +p->basic.raw[0x4] = p->basic.raw[0x7] = p->basic.raw[0xd] = EMPTY_LEAF;
> How come you play with leaves 7 and 0xd here?
This particular piece of clobbering was something which has only just
occurred to me now when implementing the leaf 4 union.
Then again, there is no supported way of getting any values into those
particular rows, or reading out of them, so I could just rely on no-one
caring?
>
>> @@ -244,6 +248,25 @@ static void __init calculate_raw_policy(void)
>> cpuid_leaf(i, &p->basic.raw[i]);
>> }
>>
>> +if ( p->basic.max_leaf >= 4 )
>> +{
>> +for ( i = 0; i < ARRAY_SIZE(p->cache.raw); ++i )
>> +{
>> +cpuid_count_leaf(4, i, &p->cache.raw[i]);
>> +
>> +if ( p->cache.subleaf[i].type == 0 )
>> +break;
>> +}
>> +
>> +/*
>> + * The choice of CPUID_GUEST_NR_CACHE is arbitrary. It is expected
>> + * that it will eventually need increasing for future hardware.
>> + */
>> +if ( i == ARRAY_SIZE(p->cache.raw) )
>> +printk(XENLOG_WARNING
>> + "CPUID: Insufficient Leaf 4 space for this hardware\n");
>> +}
> It probably doesn't hurt, but it's one off: There's no enough space
> only when the next (i-th) doesn't report type 0.
This bit of logic is slightly awkward. We read into p->cache.raw[i]
before looking to see whether p->cache.subleaf[i].type is the end of the
list. As such we always read one-past-the-end.
>
>> @@ -125,6 +126,15 @@ struct cpuid_policy
>> };
>> } basic;
>>
>> +/* Structured cache leaf: 0x0004[xx] */
>> +union {
>> +struct cpuid_leaf raw[CPUID_GUEST_NR_CACHE];
>> +struct {
>> +uint32_t type:4,
> According to the SDM version I'm looking at this is a 5 bit field.
Right you are. I'd got confused by the "Bits 04 - 00". Will fix.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: warn if dom0_mem is not specified
On Tue, 21 Feb 2017, Wei Liu wrote:
> On Mon, Feb 20, 2017 at 10:22:06AM -0800, Stefano Stabellini wrote:
> > The default dom0_mem is 128M which is not sufficient to boot a Ubuntu
> > based Dom0. It is not clear what a better default value could be.
> >
> > Instead, loudly warn the user when dom0_mem is unspecified and wait 3
> > secs. Then use 512M.
> >
> > Update the docs to specify that dom0_mem is required on ARM. (The
> > current xen-command-line document does not actually reflect the current
> > behavior of dom0_mem on ARM correctly.)
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> > Changes in v3:
> > - update docs
> > ---
> > docs/misc/xen-command-line.markdown | 8 +++-
> > xen/arch/arm/domain_build.c | 22 +-
> > 2 files changed, 24 insertions(+), 6 deletions(-)
> >
> > diff --git a/docs/misc/xen-command-line.markdown
> > b/docs/misc/xen-command-line.markdown
> > index a11fdf9..c0106fb 100644
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -603,7 +603,13 @@ For example, with `dom0_max_vcpus=4-8`:
> > > 8| 8
> > > 10| 8
> >
> > -### dom0\_mem
> > +### dom0\_mem (ARM)
> > +> `= `
> > +
> > +Set the amount of memory for the initial domain (dom0). It must be
> > +greater than zero. This parameter is required.
> > +
> > +### dom0\_mem (x86)
> > > `= List of ( min: | max: | )`
> >
> > Set the amount of memory for the initial domain (dom0). If a size is
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index c97a1f5..db7471f 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -1,4 +1,5 @@
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -31,14 +32,11 @@ integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
> >
> > int dom0_11_mapping = 1;
> >
> > -#define DOM0_MEM_DEFAULT 0x800 /* 128 MiB */
> > -static u64 __initdata dom0_mem = DOM0_MEM_DEFAULT;
> > +static u64 __initdata dom0_mem;
> >
> > static void __init parse_dom0_mem(const char *s)
> > {
> > dom0_mem = parse_size_and_unit(s, &s);
> > -if ( dom0_mem == 0 )
> > -dom0_mem = DOM0_MEM_DEFAULT;
> > }
> > custom_param("dom0_mem", parse_dom0_mem);
> >
> > @@ -2125,7 +2123,21 @@ int construct_dom0(struct domain *d)
> > BUG_ON(d->vcpu[0] == NULL);
> > BUG_ON(v->is_initialised);
> >
> > -printk("*** LOADING DOMAIN 0 ***\n");
> > +if ( dom0_mem > 0 )
> > +printk("*** LOADING DOMAIN 0 ***\n");
> > +else
> > +{
> > +int i;
> > +printk("*** PLEASE SPECIFY dom0_mem PARAMETER - USING 512M FOR NOW
> > ***\n");
> > +for (i = 0; i < 3; i++)
> > +{
> > +printk("%d...", i+1);
> > +mdelay(1000);
>
> There is infrastructure in Xen to print warning messages, so that we
> don't add delays unnecessarily.
>
> See warning.h:warning_add.
I added the delay on purpose to force the user to specify dom0_mem, as
we cannot find a way to set a sensible default. The alternative is to
panic.
> > +}
> > +printk("\n");
> > +dom0_mem = MB(512);
> > +}
> > +
> >
> > iommu_hwdom_init(d);
> >
> > --
> > 1.9.1
> >
> >
> > ___
> > 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] xen/arm: warn if dom0_mem is not specified
Hi Stefano,
On 21/02/17 17:26, Stefano Stabellini wrote:
On Tue, 21 Feb 2017, Wei Liu wrote:
On Mon, Feb 20, 2017 at 10:22:06AM -0800, Stefano Stabellini wrote:
The default dom0_mem is 128M which is not sufficient to boot a Ubuntu
based Dom0. It is not clear what a better default value could be.
Instead, loudly warn the user when dom0_mem is unspecified and wait 3
secs. Then use 512M.
Update the docs to specify that dom0_mem is required on ARM. (The
current xen-command-line document does not actually reflect the current
behavior of dom0_mem on ARM correctly.)
Signed-off-by: Stefano Stabellini
---
Changes in v3:
- update docs
---
docs/misc/xen-command-line.markdown | 8 +++-
xen/arch/arm/domain_build.c | 22 +-
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index a11fdf9..c0106fb 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -603,7 +603,13 @@ For example, with `dom0_max_vcpus=4-8`:
> 8| 8
> 10| 8
-### dom0\_mem
+### dom0\_mem (ARM)
+> `= `
+
+Set the amount of memory for the initial domain (dom0). It must be
+greater than zero. This parameter is required.
+
+### dom0\_mem (x86)
> `= List of ( min: | max: | )`
Set the amount of memory for the initial domain (dom0). If a size is
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c97a1f5..db7471f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1,4 +1,5 @@
#include
+#include
#include
#include
#include
@@ -31,14 +32,11 @@ integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
int dom0_11_mapping = 1;
-#define DOM0_MEM_DEFAULT 0x800 /* 128 MiB */
-static u64 __initdata dom0_mem = DOM0_MEM_DEFAULT;
+static u64 __initdata dom0_mem;
static void __init parse_dom0_mem(const char *s)
{
dom0_mem = parse_size_and_unit(s, &s);
-if ( dom0_mem == 0 )
-dom0_mem = DOM0_MEM_DEFAULT;
}
custom_param("dom0_mem", parse_dom0_mem);
@@ -2125,7 +2123,21 @@ int construct_dom0(struct domain *d)
BUG_ON(d->vcpu[0] == NULL);
BUG_ON(v->is_initialised);
-printk("*** LOADING DOMAIN 0 ***\n");
+if ( dom0_mem > 0 )
+printk("*** LOADING DOMAIN 0 ***\n");
+else
+{
+int i;
+printk("*** PLEASE SPECIFY dom0_mem PARAMETER - USING 512M FOR NOW
***\n");
+for (i = 0; i < 3; i++)
+{
+printk("%d...", i+1);
+mdelay(1000);
There is infrastructure in Xen to print warning messages, so that we
don't add delays unnecessarily.
See warning.h:warning_add.
I added the delay on purpose to force the user to specify dom0_mem, as
we cannot find a way to set a sensible default. The alternative is to
panic.
warning_add will gather the warning message and then will be printed at
the end of the boot with a delay. This is what is used for sync_console
message and also FEP on x86.
I think this is a good idea to gather all the warnings and print them at
the end. At least it is not lost in the noise.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 03/10] x86/cpuid: Handle leaf 0x1 in guest_cpuid()
On 21/02/17 17:20, Jan Beulich wrote: > The final 8 bits are the initial legacy APIC ID. For HVM guests, this was overridden to vcpu_id * 2. The same logic is now applied to PV guests, so guests don't observe a constant number on all vcpus via their emulated or faulted view. >>> They won't be the same everywhere, but every 128th CPU will >>> share values. I'm therefore not sure it wouldn't be better to hand >>> out zero or all ones here. >> There is no case where 128 cpus work sensibly under Xen ATM. > For HVM you mean. I'm sure I've seen > 128 vCPU PV guests > (namely Dom0-s). You can physically create PV domains with up to 8192 vcpus. I tried this once. The NMI watchdog (even set to 10s) is unforgiving of some the for_each_vcpu() loops during domain destruction. I can also still create workloads in a 64vcpu HVM guest which will cause a 5 second watchdog timeout, which is why XenServers upper supported vcpu limit is still 32. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 06/10] x86/cpuid: Handle leaf 0x6 in guest_cpuid()
>>> On 20.02.17 at 12:00, wrote: > The thermal/performance leaf was previously hidden from HVM guests, but fully > visible to PV guests. Most of the leaf refers to MSR availability, and there > is nothing an unprivileged PV guest can do with the information, so hide the > leaf entirely. > > The PV MSR handling logic as minimal support for some thermal/perf operations ... has ... > from the hardware domain, so leak through the implemented subset of > features. Does it make sense to continue to special case PV hwdom here? Should there perhaps be at least a fixme note? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 05/10] x86/cpuid: Handle leaf 0x5 in guest_cpuid()
>>> On 20.02.17 at 12:00, wrote: > The MONITOR flag isn't exposed to guests. The existing toolstack logic, and > pv_cpuid() in the hypervisor, zero the MONITOR leaf for queries. > > However, the MONITOR leaf is still visible in the hardware domains native > CPUID view, and Linux depends on this to set up C-state information. Leak the > hosts MONITOR leaf under the same circumstances that the MONITOR feature is > leaked. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] VLAPIC and Event channel relationship or how to map PIRQ to HVM guest?
Hello guys, Could someone help me with VLAPIC and Event channel relationship? I can't find any good design overview for it. Are they compatible things or not? Actually I want to map any PIRQ to HVM guest (for example keyboard), and use VLAPIC to deliver virtual interrupt to HVM guest. But seems like all interrupts from keyboard are working through the Event Channel Upcall Interrupt with vector 243. Please, help me or point any useful documentation. Thank you! Best Regards, Rockosov Dmitry ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 03/10] x86/cpuid: Handle leaf 0x1 in guest_cpuid()
>>> On 21.02.17 at 18:13, wrote:
> On 21/02/17 16:59, Jan Beulich wrote:
> On 20.02.17 at 12:00, wrote:
>>> The ebx word is more problematic. The low 8 bits are the brand ID and safe
>>> to
>>> pass straight through. The next 8 bits are the CLFLUSH line size. This
>>> value
>>> is forwarded straight from hardware, as nothing good can possibly come of
>>> providing an alternative value to the guest.
>> Risking the value guests see to change across migration.
>
> CPUID state isn't sent in the migration stream. It is still regenerated
> from scratch on the destination side, thus has always (potentially) been
> changing under the feet of the guest.
True.
>>> The final 8 bits are the initial legacy APIC ID. For HVM guests, this was
>>> overridden to vcpu_id * 2. The same logic is now applied to PV guests, so
>>> guests don't observe a constant number on all vcpus via their emulated or
>>> faulted view.
>> They won't be the same everywhere, but every 128th CPU will
>> share values. I'm therefore not sure it wouldn't be better to hand
>> out zero or all ones here.
>
> There is no case where 128 cpus work sensibly under Xen ATM.
For HVM you mean. I'm sure I've seen > 128 vCPU PV guests
(namely Dom0-s).
> On real hardware, this APIC ID field does start repeating, so IMO it is
> the correct action to take.
Oh, right. That's fine then.
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -176,6 +176,9 @@ static void recalculate_misc(struct cpuid_policy *p)
>>> switch ( p->x86_vendor )
>>> {
>>> case X86_VENDOR_INTEL:
>>> +p->basic.raw_fms &= 0x0fff3fff;
>> Wouldn't it be better to use the same mask as for AMD here? The
>> field is effectively unused / reserved on 64-bit processors.
>
> Perhaps.
>
>>
>>> @@ -967,6 +920,12 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
>>> break;
>>>
>>> case 0x8001:
>>> +/* SYSCALL is hidden outside of long mode on Intel. */
>>> +if ( p->x86_vendor == X86_VENDOR_INTEL &&
>>> + has_hvm_container_domain(d) && !hvm_long_mode_enabled(v) )
>>> +res->d &= ~cpufeat_mask(X86_FEATURE_SYSCALL);
>>> +
>>> +common_dynamic_adjustments: /* Adjustments common with leaf 1. */
>> Perhaps have "leaf1" in the label named then?
>
> Ok.
With those (last) two adjustments,
Reviewed-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 02/10] x86/gen-cpuid: Clarify the intended meaning of AVX wrt feature dependencies
>>> On 21.02.17 at 18:12, wrote:
> Which particular feature groups? I could extend that text to say
>
> "VEX/XOP-encoded GPR instructions, such as those from the BMI{1,2} and
> $X sets..."
TBM and LWP.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 04/10] x86/cpuid: Handle leaf 0x4 in guest_cpuid()
>>> On 20.02.17 at 12:00, wrote:
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -163,6 +163,9 @@ static void recalculate_xstate(struct cpuid_policy *p)
> */
> static void recalculate_misc(struct cpuid_policy *p)
> {
> +/* Leaves with subleaf unions. */
> +p->basic.raw[0x4] = p->basic.raw[0x7] = p->basic.raw[0xd] = EMPTY_LEAF;
How come you play with leaves 7 and 0xd here?
> @@ -244,6 +248,25 @@ static void __init calculate_raw_policy(void)
> cpuid_leaf(i, &p->basic.raw[i]);
> }
>
> +if ( p->basic.max_leaf >= 4 )
> +{
> +for ( i = 0; i < ARRAY_SIZE(p->cache.raw); ++i )
> +{
> +cpuid_count_leaf(4, i, &p->cache.raw[i]);
> +
> +if ( p->cache.subleaf[i].type == 0 )
> +break;
> +}
> +
> +/*
> + * The choice of CPUID_GUEST_NR_CACHE is arbitrary. It is expected
> + * that it will eventually need increasing for future hardware.
> + */
> +if ( i == ARRAY_SIZE(p->cache.raw) )
> +printk(XENLOG_WARNING
> + "CPUID: Insufficient Leaf 4 space for this hardware\n");
> +}
It probably doesn't hurt, but it's one off: There's no enough space
only when the next (i-th) doesn't report type 0.
> @@ -125,6 +126,15 @@ struct cpuid_policy
> };
> } basic;
>
> +/* Structured cache leaf: 0x0004[xx] */
> +union {
> +struct cpuid_leaf raw[CPUID_GUEST_NR_CACHE];
> +struct {
> +uint32_t type:4,
According to the SDM version I'm looking at this is a 5 bit field.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 03/10] x86/cpuid: Handle leaf 0x1 in guest_cpuid()
On 21/02/17 16:59, Jan Beulich wrote:
On 20.02.17 at 12:00, wrote:
>> The ebx word is more problematic. The low 8 bits are the brand ID and safe
>> to
>> pass straight through. The next 8 bits are the CLFLUSH line size. This
>> value
>> is forwarded straight from hardware, as nothing good can possibly come of
>> providing an alternative value to the guest.
> Risking the value guests see to change across migration.
CPUID state isn't sent in the migration stream. It is still regenerated
from scratch on the destination side, thus has always (potentially) been
changing under the feet of the guest.
All this logic is doing is preventing the toolstack from offering
anything but the real hardware value.
With the planned extra toolstack and migration logic in place,
clflush_size being different will be a hard failure to migrate, as it is
not safe for the guest.
>
>> The final 8 bits are the initial legacy APIC ID. For HVM guests, this was
>> overridden to vcpu_id * 2. The same logic is now applied to PV guests, so
>> guests don't observe a constant number on all vcpus via their emulated or
>> faulted view.
> They won't be the same everywhere, but every 128th CPU will
> share values. I'm therefore not sure it wouldn't be better to hand
> out zero or all ones here.
There is no case where 128 cpus work sensibly under Xen ATM.
On real hardware, this APIC ID field does start repeating, so IMO it is
the correct action to take.
>
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -176,6 +176,9 @@ static void recalculate_misc(struct cpuid_policy *p)
>> switch ( p->x86_vendor )
>> {
>> case X86_VENDOR_INTEL:
>> +p->basic.raw_fms &= 0x0fff3fff;
> Wouldn't it be better to use the same mask as for AMD here? The
> field is effectively unused / reserved on 64-bit processors.
Perhaps.
>
>> @@ -967,6 +920,12 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
>> break;
>>
>> case 0x8001:
>> +/* SYSCALL is hidden outside of long mode on Intel. */
>> +if ( p->x86_vendor == X86_VENDOR_INTEL &&
>> + has_hvm_container_domain(d) && !hvm_long_mode_enabled(v) )
>> +res->d &= ~cpufeat_mask(X86_FEATURE_SYSCALL);
>> +
>> +common_dynamic_adjustments: /* Adjustments common with leaf 1. */
> Perhaps have "leaf1" in the label named then?
Ok.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 02/10] x86/gen-cpuid: Clarify the intended meaning of AVX wrt feature dependencies
On 21/02/17 17:07, Jan Beulich wrote:
On 21.02.17 at 17:53, wrote:
>> On 21/02/17 16:47, Jan Beulich wrote:
>> On 21.02.17 at 17:40, wrote:
>>> On 20.02.17 at 12:00, wrote:
> --- a/xen/tools/gen-cpuid.py
> +++ b/xen/tools/gen-cpuid.py
> @@ -225,9 +225,13 @@ def crunch_numbers(state):
> XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES,
> AVX, MPX, PKU, LWP],
>
> -# AVX is taken to mean hardware support for VEX encoded
> instructions,
> -# 256bit registers, and the instructions themselves. Each of
> these
> -# subsequent instruction groups may only be VEX encoded.
> +# AVX is taken to mean hardware support for 256bit registers
> (which in
> +# practice depends on the VEX prefix to encode), and the
> instructions
> +# themselves.
> +#
> +# AVX is not taken to mean support for the VEX prefix itself.
> +# VEX-encoded GPR instructions, such as those from the BMI{1,2}
> sets
> +# function fine in the absence of any enabled xstate.
> AVX: [FMA, FMA4, F16C, AVX2, XOP],
Even if there aren't any EVEX-encoded non-AVX512 instructions so
far, I'd prefer the AVX512F entry to get adjusted along the same
lines. With that
Reviewed-by: Jan Beulich
>>> Actually, one more thing: XOP really has dual meaning (encoding
>>> and certain SIMD instructions). Perhaps it would be good to clarify
>>> this here too.
>> We don't currently express any dependencies based on XOP, so there is no
>> text about it.
> Well, I'm referring to the text (and dependency) above. In
> particular the dependency is meant for the XOP-encoded SIMD
> insns (which the XOP feature flag represents), not the XOP-encoded
> GPR ones (which have distinct feature flags, but the naming sadly
> collides).
Which particular feature groups? I could extend that text to say
"VEX/XOP-encoded GPR instructions, such as those from the BMI{1,2} and
$X sets..."
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 02/10] x86/gen-cpuid: Clarify the intended meaning of AVX wrt feature dependencies
>>> On 21.02.17 at 17:53, wrote:
> On 21/02/17 16:47, Jan Beulich wrote:
> On 21.02.17 at 17:40, wrote:
>> On 20.02.17 at 12:00, wrote:
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -225,9 +225,13 @@ def crunch_numbers(state):
XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES,
AVX, MPX, PKU, LWP],
-# AVX is taken to mean hardware support for VEX encoded
instructions,
-# 256bit registers, and the instructions themselves. Each of
these
-# subsequent instruction groups may only be VEX encoded.
+# AVX is taken to mean hardware support for 256bit registers
(which in
+# practice depends on the VEX prefix to encode), and the
instructions
+# themselves.
+#
+# AVX is not taken to mean support for the VEX prefix itself.
+# VEX-encoded GPR instructions, such as those from the BMI{1,2}
sets
+# function fine in the absence of any enabled xstate.
AVX: [FMA, FMA4, F16C, AVX2, XOP],
>>> Even if there aren't any EVEX-encoded non-AVX512 instructions so
>>> far, I'd prefer the AVX512F entry to get adjusted along the same
>>> lines. With that
>>> Reviewed-by: Jan Beulich
>> Actually, one more thing: XOP really has dual meaning (encoding
>> and certain SIMD instructions). Perhaps it would be good to clarify
>> this here too.
>
> We don't currently express any dependencies based on XOP, so there is no
> text about it.
Well, I'm referring to the text (and dependency) above. In
particular the dependency is meant for the XOP-encoded SIMD
insns (which the XOP feature flag represents), not the XOP-encoded
GPR ones (which have distinct feature flags, but the naming sadly
collides).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 03/10] x86/cpuid: Handle leaf 0x1 in guest_cpuid()
>>> On 20.02.17 at 12:00, wrote:
> The ebx word is more problematic. The low 8 bits are the brand ID and safe to
> pass straight through. The next 8 bits are the CLFLUSH line size. This value
> is forwarded straight from hardware, as nothing good can possibly come of
> providing an alternative value to the guest.
Risking the value guests see to change across migration.
> The final 8 bits are the initial legacy APIC ID. For HVM guests, this was
> overridden to vcpu_id * 2. The same logic is now applied to PV guests, so
> guests don't observe a constant number on all vcpus via their emulated or
> faulted view.
They won't be the same everywhere, but every 128th CPU will
share values. I'm therefore not sure it wouldn't be better to hand
out zero or all ones here.
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -176,6 +176,9 @@ static void recalculate_misc(struct cpuid_policy *p)
> switch ( p->x86_vendor )
> {
> case X86_VENDOR_INTEL:
> +p->basic.raw_fms &= 0x0fff3fff;
Wouldn't it be better to use the same mask as for AMD here? The
field is effectively unused / reserved on 64-bit processors.
> @@ -967,6 +920,12 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
> break;
>
> case 0x8001:
> +/* SYSCALL is hidden outside of long mode on Intel. */
> +if ( p->x86_vendor == X86_VENDOR_INTEL &&
> + has_hvm_container_domain(d) && !hvm_long_mode_enabled(v) )
> +res->d &= ~cpufeat_mask(X86_FEATURE_SYSCALL);
> +
> +common_dynamic_adjustments: /* Adjustments common with leaf 1. */
Perhaps have "leaf1" in the label named then?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: introduce vwfi parameter
On 21/02/17 15:14, Julien Grall wrote: > Hi George, > > On 21/02/17 13:46, George Dunlap wrote: >> I think our options look like: > > Thank you for the summary of the options! > >> >> A. Don't trap guest WFI at all -- allow it to 'halt' in >> moderate-power-but-ready-for-interrupt mode. >> >> B. Trap guest WFI and block normally. >> >> C. Trap guest WFI and poll instead of idling. >> >> D. Trap guest WFI and take that as a hint to "idle" in a non-deep sleep >> state (perhaps, for instance, using the WFI instruction). >> >> A is safe because the scheduler should already have set a timer to break >> out of it if necessary. The only potential issue here is that the guest >> is burning its credits, meaning that other vcpus with something >> potentially useful to do aren't being allowed to run; and then later >> when this vcpu has something useful to do it may be prevented from >> running because of low credits. (This may be what Dario means when he >> says it "breaks scheduling"). >> >> B, C, and D have the advantage that the guest will not be charged for >> credits, and other useful work can be done if it's possible. >> >> B and C have the disadvantage that the effect will be significantly >> different under Xen than on real hardware: B will mean it will go into a >> deep sleep state (and thus not be as responsive as on real hardare); C >> has the disadvantage that there won't be any significant power savings. > > I'd like to correct one misunderstanding here. Today the idle_loop on > ARM is doing a WFI. This is not a deep-sleep state, it is fairly quite > quick to come back. What really cost if the context switch of the state > of the vCPU during blocking. > > So I think B and D are the same. Or did you expect D to not switch to > the idle vCPU? > > Note, it is possible to implement more deep-sleep state on ARM either > via PSCI or platform specific code. Oh, right; so it sounds a bit as if WFI is ARM's version of x86 HLT. I thought it was more special. :-) Things get a bit tricky because one of the purposes of a hypervisor is to deal with more advanced hardware so that the guest OS doesn't have to. For instance, it would make sense to have simple guest OSes that only know how to do WFI, and then have Xen have the smarts to know if and when to go into a deeper sleep state. So you wouldn't normally want to have WFI be a hint *not* to go into a deep sleep state, unless you were sure that nearly all your guest operating systems would know how to say "actually go ahead into a deep sleep state", and said that by default. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 105953: tolerable trouble: broken/fail/pass - PUSHED
flight 105953 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105953/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen-buildfail never pass
build-arm64-pvops 5 kernel-build fail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
version targeted for testing:
xen b908131167a67a16fbe9c7a7826b67e2d93d9ec5
baseline version:
xen 38b48605f3693e950bb4155ea8dac6614d796c2b
Last test of basis 105950 2017-02-21 12:01:15 Z0 days
Testing same since 105953 2017-02-21 15:02:01 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Kevin Tian
jobs:
build-amd64 pass
build-arm64 fail
build-armhf pass
build-amd64-libvirt pass
build-arm64-pvopsfail
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm broken
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=b908131167a67a16fbe9c7a7826b67e2d93d9ec5
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
b908131167a67a16fbe9c7a7826b67e2d93d9ec5
+ branch=xen-unstable-smoke
+ revision=b908131167a67a16fbe9c7a7826b67e2d93d9ec5
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' xb908131167a67a16fbe9c7a7826b67e2d93d9ec5 = 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://g
Re: [Xen-devel] [PATCH 02/10] x86/gen-cpuid: Clarify the intended meaning of AVX wrt feature dependencies
On 21/02/17 16:47, Jan Beulich wrote:
On 21.02.17 at 17:40, wrote:
> On 20.02.17 at 12:00, wrote:
>>> --- a/xen/tools/gen-cpuid.py
>>> +++ b/xen/tools/gen-cpuid.py
>>> @@ -225,9 +225,13 @@ def crunch_numbers(state):
>>> XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES,
>>> AVX, MPX, PKU, LWP],
>>>
>>> -# AVX is taken to mean hardware support for VEX encoded
>>> instructions,
>>> -# 256bit registers, and the instructions themselves. Each of these
>>> -# subsequent instruction groups may only be VEX encoded.
>>> +# AVX is taken to mean hardware support for 256bit registers
>>> (which in
>>> +# practice depends on the VEX prefix to encode), and the
>>> instructions
>>> +# themselves.
>>> +#
>>> +# AVX is not taken to mean support for the VEX prefix itself.
>>> +# VEX-encoded GPR instructions, such as those from the BMI{1,2}
>>> sets
>>> +# function fine in the absence of any enabled xstate.
>>> AVX: [FMA, FMA4, F16C, AVX2, XOP],
>> Even if there aren't any EVEX-encoded non-AVX512 instructions so
>> far, I'd prefer the AVX512F entry to get adjusted along the same
>> lines. With that
>> Reviewed-by: Jan Beulich
> Actually, one more thing: XOP really has dual meaning (encoding
> and certain SIMD instructions). Perhaps it would be good to clarify
> this here too.
We don't currently express any dependencies based on XOP, so there is no
text about it.
As AMD have dropped XOP encoding in their Zen line, I don't expect this
will change going forwards.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [ovmf baseline-only test] 68588: regressions - FAIL
This run is configured for baseline tests only. flight 68588 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68588/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-boot fail REGR. vs. 68582 version targeted for testing: ovmf 5af4388433e13ffeda980116d92f4230c79e483d baseline version: ovmf c035e37335ae43229d7e68de74a65f2c01ebc0af Last test of basis68582 2017-02-20 05:19:15 Z1 days Testing same since68588 2017-02-21 12:17:08 Z0 days1 attempts People who touched revisions under test: Star Zeng 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 fail test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 5af4388433e13ffeda980116d92f4230c79e483d Author: Star Zeng Date: Mon Feb 20 14:13:42 2017 +0800 Security Tcg2Smm: Add missing gEfiTcg2ProtocolGuid dependency REF: https://bugzilla.tianocore.org/show_bug.cgi?id=380 gEfiTcgProtocolGuid dependency was added in TcgSmm. But gEfiTcg2ProtocolGuid dependency is missing in Tcg2Smm. Cc: Jiewen Yao Cc: Chao Zhang Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng Reviewed-by: Jiewen Yao ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: introduce vwfi parameter
On Tue, 2017-02-21 at 12:30 +, Julien Grall wrote: > On 21/02/2017 09:09, Dario Faggioli wrote: > > Well, TBH, we still are not entirely sure who the culprit is for > > high > > latency. There are spikes in Credit2, and I'm investigating that. > > But > > apart from them? I think we need other numbers with which we can > > compare the numbers that Stefano has collected. > > I think the problem is because we save/restore the vCPU state when > switching to the idle vCPU. > That may well be. Or at least, that may well be part of the problem. I don't know enough of ARM to know whether it's the predominant cause of high latencies or not. On x86, on Linux, polling is used to prevent the CPU to go in deep C-states. I was assuming things to be similar on ARM, and that's the reason why I thought introducing a polling mode could have been useful (although wasteful). But you guys are the ones that know whether or not that is the case (and in another email, you seem to say it's not). > Let say the only 1 vCPU can run on the pCPU, when the vCPU is issuing > a > WFI the following steps will happen: > * WFI trapped and vcpu blocked > * save vCPU state > * run idle_loop > -> Interrupt incoming for the guest > * restore vCPU state > * back to the guest > > Saving/restoring on ARM requires to context switch all the state of > the > VM (this is not saved in memory when entering in the hypervisor). > This > include things like system register, interrupt controller state, > FPU... > Yes. In fact, on x86, we have what we call 'lazy context switch', which deals specifically with some aspect of this situation. Indeed it seems like implementing the same on ARM --if you don't have it already, and if possible-- would be useful in this case too. 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 02/10] x86/gen-cpuid: Clarify the intended meaning of AVX wrt feature dependencies
>>> On 21.02.17 at 17:40, wrote:
On 20.02.17 at 12:00, wrote:
>> --- a/xen/tools/gen-cpuid.py
>> +++ b/xen/tools/gen-cpuid.py
>> @@ -225,9 +225,13 @@ def crunch_numbers(state):
>> XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES,
>> AVX, MPX, PKU, LWP],
>>
>> -# AVX is taken to mean hardware support for VEX encoded
>> instructions,
>> -# 256bit registers, and the instructions themselves. Each of these
>> -# subsequent instruction groups may only be VEX encoded.
>> +# AVX is taken to mean hardware support for 256bit registers (which
>> in
>> +# practice depends on the VEX prefix to encode), and the
>> instructions
>> +# themselves.
>> +#
>> +# AVX is not taken to mean support for the VEX prefix itself.
>> +# VEX-encoded GPR instructions, such as those from the BMI{1,2} sets
>> +# function fine in the absence of any enabled xstate.
>> AVX: [FMA, FMA4, F16C, AVX2, XOP],
>
> Even if there aren't any EVEX-encoded non-AVX512 instructions so
> far, I'd prefer the AVX512F entry to get adjusted along the same
> lines. With that
> Reviewed-by: Jan Beulich
Actually, one more thing: XOP really has dual meaning (encoding
and certain SIMD instructions). Perhaps it would be good to clarify
this here too.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 02/10] x86/gen-cpuid: Clarify the intended meaning of AVX wrt feature dependencies
On 21/02/17 16:40, Jan Beulich wrote:
On 20.02.17 at 12:00, wrote:
>> --- a/xen/tools/gen-cpuid.py
>> +++ b/xen/tools/gen-cpuid.py
>> @@ -225,9 +225,13 @@ def crunch_numbers(state):
>> XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES,
>> AVX, MPX, PKU, LWP],
>>
>> -# AVX is taken to mean hardware support for VEX encoded
>> instructions,
>> -# 256bit registers, and the instructions themselves. Each of these
>> -# subsequent instruction groups may only be VEX encoded.
>> +# AVX is taken to mean hardware support for 256bit registers (which
>> in
>> +# practice depends on the VEX prefix to encode), and the
>> instructions
>> +# themselves.
>> +#
>> +# AVX is not taken to mean support for the VEX prefix itself.
>> +# VEX-encoded GPR instructions, such as those from the BMI{1,2} sets
>> +# function fine in the absence of any enabled xstate.
>> AVX: [FMA, FMA4, F16C, AVX2, XOP],
> Even if there aren't any EVEX-encoded non-AVX512 instructions so
> far, I'd prefer the AVX512F entry to get adjusted along the same
> lines.
Good point. I will update.
> With that Reviewed-by: Jan Beulich
Thanks,
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 02/10] x86/gen-cpuid: Clarify the intended meaning of AVX wrt feature dependencies
>>> On 20.02.17 at 12:00, wrote:
> --- a/xen/tools/gen-cpuid.py
> +++ b/xen/tools/gen-cpuid.py
> @@ -225,9 +225,13 @@ def crunch_numbers(state):
> XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES,
> AVX, MPX, PKU, LWP],
>
> -# AVX is taken to mean hardware support for VEX encoded instructions,
> -# 256bit registers, and the instructions themselves. Each of these
> -# subsequent instruction groups may only be VEX encoded.
> +# AVX is taken to mean hardware support for 256bit registers (which
> in
> +# practice depends on the VEX prefix to encode), and the instructions
> +# themselves.
> +#
> +# AVX is not taken to mean support for the VEX prefix itself.
> +# VEX-encoded GPR instructions, such as those from the BMI{1,2} sets
> +# function fine in the absence of any enabled xstate.
> AVX: [FMA, FMA4, F16C, AVX2, XOP],
Even if there aren't any EVEX-encoded non-AVX512 instructions so
far, I'd prefer the AVX512F entry to get adjusted along the same
lines. With that
Reviewed-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 01/10] x86/cpuid: Disallow policy updates once the domain is running
>>> On 20.02.17 at 12:00, wrote: > On real hardware, the bulk of CPUID data is system-specific and constant. > Hold the toolstack to the same behaviour when constructing domains. > > Values which are expected to change dynamically (e.g. OSXSAVE) are > unaffected > and continue to function as before. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data
On 02/21/2017 10:45 AM, Juergen Gross wrote:
> On 21/02/17 16:31, Dan Streetman wrote:
>> On Fri, Jan 13, 2017 at 5:30 PM, Konrad Rzeszutek Wilk
>> wrote:
>>> On Fri, Jan 13, 2017 at 03:07:51PM -0500, Dan Streetman wrote:
Revert the main part of commit:
af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
That commit introduced reading the pci device's msi message data to see
if a pirq was previously configured for the device's msi/msix, and re-use
that pirq. At the time, that was the correct behavior. However, a
later change to Qemu caused it to call into the Xen hypervisor to unmap
all pirqs for a pci device, when the pci device disables its MSI/MSIX
vectors; specifically the Qemu commit:
c976437c7dba9c7444fb41df45468968aaa326ad
("qemu-xen: free all the pirqs for msi/msix when driver unload")
Once Qemu added this pirq unmapping, it was no longer correct for the
kernel to re-use the pirq number cached in the pci device msi message
data. All Qemu releases since 2.1.0 contain the patch that unmaps the
pirqs when the pci device disables its MSI/MSIX vectors.
This bug is causing failures to initialize multiple NVMe controllers
under Xen, because the NVMe driver sets up a single MSIX vector for
each controller (concurrently), and then after using that to talk to
the controller for some configuration data, it disables the single MSIX
vector and re-configures all the MSIX vectors it needs. So the MSIX
setup code tries to re-use the cached pirq from the first vector
for each controller, but the hypervisor has already given away that
pirq to another controller, and its initialization fails.
This is discussed in more detail at:
https://lists.xen.org/archives/html/xen-devel/2017-01/msg00447.html
Fixes: af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM
guests")
Signed-off-by: Dan Streetman
>>> Acked-by: Konrad Rzeszutek Wilk
>> This doesn't seem to be applied yet, is it still waiting on another
>> ack? Or maybe I'm looking at the wrong git tree...
> Am I wrong or shouldn't this go through the PCI tree? Konrad?
Konrad is away this week but since pull request for Xen tree just went
out we should probably wait until rc1 anyway (unless something big comes
up before that).
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] tools: move xl to a dedicated directory
It makes clear distinction between the client (xl) and library (libxl),
which should help design better APIs. This will also help reduce the
code size in libxl directory.
Signed-off-by: Wei Liu
---
.gitignore | 2 +-
tools/libxl/Makefile| 22 ---
tools/xl/Makefile | 43 +
tools/{libxl => xl}/bash-completion | 0
tools/{libxl => xl}/xl.c| 0
tools/{libxl => xl}/xl.h| 0
tools/{libxl => xl}/xl_cmdimpl.c| 0
tools/{libxl => xl}/xl_cmdtable.c | 0
tools/{libxl => xl}/xl_sxp.c| 0
9 files changed, 48 insertions(+), 19 deletions(-)
create mode 100644 tools/xl/Makefile
rename tools/{libxl => xl}/bash-completion (100%)
rename tools/{libxl => xl}/xl.c (100%)
rename tools/{libxl => xl}/xl.h (100%)
rename tools/{libxl => xl}/xl_cmdimpl.c (100%)
rename tools/{libxl => xl}/xl_cmdtable.c (100%)
rename tools/{libxl => xl}/xl_sxp.c (100%)
diff --git a/.gitignore b/.gitignore
index c8d56d1bdb..a785006e44 100644
--- a/.gitignore
+++ b/.gitignore
@@ -189,7 +189,6 @@ tools/libxl/ssdt*
tools/libxl/testenum
tools/libxl/testenum.c
tools/libxl/tmp.*
-tools/libxl/xl
tools/misc/cpuperf/cpuperf-perfcntr
tools/misc/cpuperf/cpuperf-xen
tools/misc/xc_shadow
@@ -380,6 +379,7 @@ tools/firmware/etherboot/ipxe/
tools/python/xen/lowlevel/xl/_pyxl_types.c
tools/python/xen/lowlevel/xl/_pyxl_types.h
tools/xenstore/xenstore-watch
+tools/xl/xl
docs/txt/misc/*.txt
docs/txt/man/*.txt
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 0f642cc57a..f00d9ef355 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -178,16 +178,9 @@ LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
$(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
-CLIENTS = xl testidl libxl-save-helper
+$(TEST_PROG_OBJS) _libxl.api-for-check: CFLAGS += $(CFLAGS_libxentoollog)
-CFLAGS_XL += $(CFLAGS_libxenlight)
-CFLAGS_XL += -Wshadow
-
-XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
-$(XL_OBJS) $(TEST_PROG_OBJS) _libxl.api-for-check: \
-CFLAGS += $(CFLAGS_libxentoollog)
-$(XL_OBJS): CFLAGS += $(CFLAGS_XL)
-$(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs
it.
+CLIENTS = testidl libxl-save-helper
libxl_dom.o: CFLAGS += -I$(XEN_ROOT)/tools # include libacpi/x86.h
libxl_x86_acpi.o: CFLAGS += -I$(XEN_ROOT)/tools
@@ -207,7 +200,7 @@ all: $(CLIENTS) $(TEST_PROGS) $(PKG_CONFIG) \
libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
$(AUTOSRCS) $(AUTOINCS)
-$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS) \
+$(LIBXL_OBJS) $(LIBXLU_OBJS) $(SAVE_HELPER_OBJS) \
$(LIBXL_TEST_OBJS) $(TEST_PROG_OBJS): \
$(AUTOINCS) libxl.api-ok
@@ -249,7 +242,7 @@ libxl_internal_json.h: _libxl_types_internal_json.h
xl.h: _paths.h
$(LIBXL_OBJS) $(LIBXL_TEST_OBJS) $(LIBXLU_OBJS) \
- $(XL_OBJS) $(TEST_PROG_OBJS) $(SAVE_HELPER_OBJS): libxl.h
+ $(TEST_PROG_OBJS) $(SAVE_HELPER_OBJS): libxl.h
$(LIBXL_OBJS) $(LIBXL_TEST_OBJS): libxl_internal.h
_libxl_type%.h _libxl_type%_json.h _libxl_type%_private.h _libxl_type%.c:
libxl_type%.idl gentypes.py idl.py
@@ -288,9 +281,6 @@ libxlutil.so.$(XLUMAJOR).$(XLUMINOR): $(LIBXLU_OBJS)
libxenlight.so
libxlutil.a: $(LIBXLU_OBJS)
$(AR) rcs libxlutil.a $^
-xl: $(XL_OBJS) libxlutil.so libxenlight.so
- $(CC) $(LDFLAGS) -o $@ $(XL_OBJS) $(LDLIBS_libxlutil)
$(LDLIBS_libxenlight) $(LDLIBS_libxentoollog) -lyajl $(APPEND_LDFLAGS)
-
test_%: test_%.o test_common.o libxlutil.so libxenlight_test.so
$(CC) $(LDFLAGS) -o $@ $^ $(filter-out %libxenlight.so,
$(LDLIBS_libxenlight)) $(LDLIBS_libxentoollog) -lyajl $(APPEND_LDFLAGS)
@@ -306,13 +296,10 @@ $(PKG_CONFIG): % : %.in Makefile
.PHONY: install
install: all
- $(INSTALL_DIR) $(DESTDIR)$(sbindir)
$(INSTALL_DIR) $(DESTDIR)$(libdir)
$(INSTALL_DIR) $(DESTDIR)$(includedir)
- $(INSTALL_DIR) $(DESTDIR)$(BASH_COMPLETION_DIR)
$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
$(INSTALL_DIR) $(DESTDIR)$(PKG_INSTALLDIR)
- $(INSTALL_PROG) xl $(DESTDIR)$(sbindir)
$(INSTALL_PROG) libxl-save-helper $(DESTDIR)$(LIBEXEC_BIN)
$(INSTALL_SHLIB) libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(libdir)
$(SYMLINK_SHLIB) libxenlight.so.$(MAJOR).$(MINOR)
$(DESTDIR)$(libdir)/libxenlight.so.$(MAJOR)
@@ -323,7 +310,6 @@ install: all
$(SYMLINK_SHLIB) libxlutil.so.$(XLUMAJOR)
$(DESTDIR)$(libdir)/libxlutil.so
$(INSTALL_DATA) libxlutil.a $(DESTDIR)$(libdir)
$(INSTALL_DATA) libxl.h libxl_event.h libxl_json.h _libxl_types.h
_libxl_types_json.h _libxl_list.h libxl_utils.h libxl_uuid.h libxlutil.h
$(DESTDIR)$(includedir)
- $(INSTALL_DATA) bash-completion $(DESTDIR)$(BASH_COMPLETION_DIR)/xl.sh
$(INSTALL_DATA) xenlight.pc $(DESTDI
[Xen-devel] [PATCH 0/2] tools: split xl into a separate directory
Xl has grown sufficiently large to warrnant its own directory. We also need
clear separation between the client (xl) and library (libxl).
This patch series moves xl into tools/xl directory.
Use find to generate a list of files to be installed from staging and wip
branch, then `diff -q staging wip`. No output is produced from diff.
I also CC some folks who will be affected by this change. If this affects your
work heavily, please let me know.
Wei Liu (2):
tools: provide libxlutil compiling and linking options
tools: move xl to a dedicated directory
.gitignore | 2 +-
tools/Rules.mk | 7 ++
tools/libxl/Makefile| 22 ---
tools/xl/Makefile | 43 +
tools/{libxl => xl}/bash-completion | 0
tools/{libxl => xl}/xl.c| 0
tools/{libxl => xl}/xl.h| 0
tools/{libxl => xl}/xl_cmdimpl.c| 0
tools/{libxl => xl}/xl_cmdtable.c | 0
tools/{libxl => xl}/xl_sxp.c| 0
10 files changed, 55 insertions(+), 19 deletions(-)
create mode 100644 tools/xl/Makefile
rename tools/{libxl => xl}/bash-completion (100%)
rename tools/{libxl => xl}/xl.c (100%)
rename tools/{libxl => xl}/xl.h (100%)
rename tools/{libxl => xl}/xl_cmdimpl.c (100%)
rename tools/{libxl => xl}/xl_cmdtable.c (100%)
rename tools/{libxl => xl}/xl_sxp.c (100%)
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] tools: provide libxlutil compiling and linking options
We are about to split out xl (which depends on libxlutil) to a different directory. Provide the proper options for compiling and linking in Rules.mk, and replace the hardcoded string in libxl/Makefile. No functional change. Signed-off-by: Wei Liu --- tools/Rules.mk | 7 +++ tools/libxl/Makefile | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/tools/Rules.mk b/tools/Rules.mk index b35999b21b..8a16013335 100644 --- a/tools/Rules.mk +++ b/tools/Rules.mk @@ -17,6 +17,8 @@ XEN_LIBXENCALL = $(XEN_ROOT)/tools/libs/call XEN_LIBXENFOREIGNMEMORY = $(XEN_ROOT)/tools/libs/foreignmemory XEN_LIBXC = $(XEN_ROOT)/tools/libxc XEN_XENLIGHT = $(XEN_ROOT)/tools/libxl +# Currently libxlutil lives in the same directory as libxenlight +XEN_XLUTIL = $(XEN_XENLIGHT) XEN_XENSTORE = $(XEN_ROOT)/tools/xenstore XEN_LIBXENSTAT = $(XEN_ROOT)/tools/xenstat/libxenstat/src XEN_BLKTAP2= $(XEN_ROOT)/tools/blktap2 @@ -172,6 +174,11 @@ SHDEPS_libxenlight = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) $(SHLIB_libblktapc LDLIBS_libxenlight = $(SHDEPS_libxenlight) $(XEN_XENLIGHT)/libxenlight$(libextension) SHLIB_libxenlight = $(SHDEPS_libxenlight) -Wl,-rpath-link=$(XEN_XENLIGHT) +CFLAGS_libxlutil = -I$(XEN_XLUTIL) +SHDEPS_libxlutil = $(SHLIB_libxenlight) +LDLIBS_libxlutil = $(SHDEPS_libxlutil) $(XEN_XENLIGHT)/libxlutil$(libextension) +SHLIB_libxlutil = $(SHDEPS_libxlutil) -Wl,-rpath-link=$(XEN_XLUTIL) + CFLAGS += -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ # Get gcc to generate the dependencies for us. diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index 6cc7b4511b..0f642cc57a 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -289,7 +289,7 @@ libxlutil.a: $(LIBXLU_OBJS) $(AR) rcs libxlutil.a $^ xl: $(XL_OBJS) libxlutil.so libxenlight.so - $(CC) $(LDFLAGS) -o $@ $(XL_OBJS) libxlutil.so $(LDLIBS_libxenlight) $(LDLIBS_libxentoollog) -lyajl $(APPEND_LDFLAGS) + $(CC) $(LDFLAGS) -o $@ $(XL_OBJS) $(LDLIBS_libxlutil) $(LDLIBS_libxenlight) $(LDLIBS_libxentoollog) -lyajl $(APPEND_LDFLAGS) test_%: test_%.o test_common.o libxlutil.so libxenlight_test.so $(CC) $(LDFLAGS) -o $@ $^ $(filter-out %libxenlight.so, $(LDLIBS_libxenlight)) $(LDLIBS_libxentoollog) -lyajl $(APPEND_LDFLAGS) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data
On 21/02/17 16:31, Dan Streetman wrote:
> On Fri, Jan 13, 2017 at 5:30 PM, Konrad Rzeszutek Wilk
> wrote:
>> On Fri, Jan 13, 2017 at 03:07:51PM -0500, Dan Streetman wrote:
>>> Revert the main part of commit:
>>> af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
>>>
>>> That commit introduced reading the pci device's msi message data to see
>>> if a pirq was previously configured for the device's msi/msix, and re-use
>>> that pirq. At the time, that was the correct behavior. However, a
>>> later change to Qemu caused it to call into the Xen hypervisor to unmap
>>> all pirqs for a pci device, when the pci device disables its MSI/MSIX
>>> vectors; specifically the Qemu commit:
>>> c976437c7dba9c7444fb41df45468968aaa326ad
>>> ("qemu-xen: free all the pirqs for msi/msix when driver unload")
>>>
>>> Once Qemu added this pirq unmapping, it was no longer correct for the
>>> kernel to re-use the pirq number cached in the pci device msi message
>>> data. All Qemu releases since 2.1.0 contain the patch that unmaps the
>>> pirqs when the pci device disables its MSI/MSIX vectors.
>>>
>>> This bug is causing failures to initialize multiple NVMe controllers
>>> under Xen, because the NVMe driver sets up a single MSIX vector for
>>> each controller (concurrently), and then after using that to talk to
>>> the controller for some configuration data, it disables the single MSIX
>>> vector and re-configures all the MSIX vectors it needs. So the MSIX
>>> setup code tries to re-use the cached pirq from the first vector
>>> for each controller, but the hypervisor has already given away that
>>> pirq to another controller, and its initialization fails.
>>>
>>> This is discussed in more detail at:
>>> https://lists.xen.org/archives/html/xen-devel/2017-01/msg00447.html
>>>
>>> Fixes: af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
>>> Signed-off-by: Dan Streetman
>>
>> Acked-by: Konrad Rzeszutek Wilk
>
> This doesn't seem to be applied yet, is it still waiting on another
> ack? Or maybe I'm looking at the wrong git tree...
Am I wrong or shouldn't this go through the PCI tree? Konrad?
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data
On Fri, Jan 13, 2017 at 5:30 PM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Jan 13, 2017 at 03:07:51PM -0500, Dan Streetman wrote:
>> Revert the main part of commit:
>> af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
>>
>> That commit introduced reading the pci device's msi message data to see
>> if a pirq was previously configured for the device's msi/msix, and re-use
>> that pirq. At the time, that was the correct behavior. However, a
>> later change to Qemu caused it to call into the Xen hypervisor to unmap
>> all pirqs for a pci device, when the pci device disables its MSI/MSIX
>> vectors; specifically the Qemu commit:
>> c976437c7dba9c7444fb41df45468968aaa326ad
>> ("qemu-xen: free all the pirqs for msi/msix when driver unload")
>>
>> Once Qemu added this pirq unmapping, it was no longer correct for the
>> kernel to re-use the pirq number cached in the pci device msi message
>> data. All Qemu releases since 2.1.0 contain the patch that unmaps the
>> pirqs when the pci device disables its MSI/MSIX vectors.
>>
>> This bug is causing failures to initialize multiple NVMe controllers
>> under Xen, because the NVMe driver sets up a single MSIX vector for
>> each controller (concurrently), and then after using that to talk to
>> the controller for some configuration data, it disables the single MSIX
>> vector and re-configures all the MSIX vectors it needs. So the MSIX
>> setup code tries to re-use the cached pirq from the first vector
>> for each controller, but the hypervisor has already given away that
>> pirq to another controller, and its initialization fails.
>>
>> This is discussed in more detail at:
>> https://lists.xen.org/archives/html/xen-devel/2017-01/msg00447.html
>>
>> Fixes: af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
>> Signed-off-by: Dan Streetman
>
> Acked-by: Konrad Rzeszutek Wilk
This doesn't seem to be applied yet, is it still waiting on another
ack? Or maybe I'm looking at the wrong git tree...
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: introduce vwfi parameter
Hi George, On 21/02/17 13:46, George Dunlap wrote: I think our options look like: Thank you for the summary of the options! A. Don't trap guest WFI at all -- allow it to 'halt' in moderate-power-but-ready-for-interrupt mode. B. Trap guest WFI and block normally. C. Trap guest WFI and poll instead of idling. D. Trap guest WFI and take that as a hint to "idle" in a non-deep sleep state (perhaps, for instance, using the WFI instruction). A is safe because the scheduler should already have set a timer to break out of it if necessary. The only potential issue here is that the guest is burning its credits, meaning that other vcpus with something potentially useful to do aren't being allowed to run; and then later when this vcpu has something useful to do it may be prevented from running because of low credits. (This may be what Dario means when he says it "breaks scheduling"). B, C, and D have the advantage that the guest will not be charged for credits, and other useful work can be done if it's possible. B and C have the disadvantage that the effect will be significantly different under Xen than on real hardware: B will mean it will go into a deep sleep state (and thus not be as responsive as on real hardare); C has the disadvantage that there won't be any significant power savings. I'd like to correct one misunderstanding here. Today the idle_loop on ARM is doing a WFI. This is not a deep-sleep state, it is fairly quite quick to come back. What really cost if the context switch of the state of the vCPU during blocking. So I think B and D are the same. Or did you expect D to not switch to the idle vCPU? Note, it is possible to implement more deep-sleep state on ARM either via PSCI or platform specific code. Having the ability for an administrator to choose between A and D seems like it would be the most useful. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: introduce vwfi parameter
On Tue, 2017-02-21 at 13:46 +, George Dunlap wrote: > > A. Don't trap guest WFI at all -- allow it to 'halt' in > moderate-power-but-ready-for-interrupt mode. > > [..] > > A is safe because the scheduler should already have set a timer to > break > out of it if necessary. The only potential issue here is that the > guest > is burning its credits, meaning that other vcpus with something > potentially useful to do aren't being allowed to run; and then later > when this vcpu has something useful to do it may be prevented from > running because of low credits. (This may be what Dario means when > he > says it "breaks scheduling"). > Are you also referring to the case when there are less vCPUs around than the host has pCPUs (and, ideally, all vCPUs are pinned 1:1 to a pCPU)? If yes, I agree that we're probably fine, but we have to check and enforce all this to be the case. If no, think at a situation where there is 1 vCPU running on a pCPU and 3 vCPUs in the runqueue (it may be a per-CPU Credit1 runqueue or a shared among some pCPUs Credit2 runqueue). If the running vCPU goes idle, let's say with WFI, we _don't_ want the pCPU to enter neither moderate nor deep sleep, we want to pick up the first of the 3 other vCPUs that are waiting in the runqueue. This is what I mean when I say "breaks scheduling". :-) Oh, actually, if --which I only now realize may be what you are referring to, since you're talking about "guest burning its credits"-- you let the vCPU put the pCPU to sleep *but*, when it wakes up (or when the scheduler runs again for whatever reason), you charge to it for all the time the the pCPU was actually idle/sleeping, well, that may actually not break scheduling, or cause disruption to the service of other vCPUs But indeed I'd consider it rather counter intuitive a behavior. In fact, it'd mean that the guest has issued WFI because he wanted to sleep and we do put it to sleep. But when it wakes up, we treat it like it had busy waited. What would be the benefit of this? That we don't context switch (either to idle or to someone else)? 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
