>>> On 15.02.18 at 17:53, wrote:
> On 15/02/18 16:03, Jan Beulich wrote:
>> --- a/xen/arch/x86/pv/emul-priv-op.c
>> +++ b/xen/arch/x86/pv/emul-priv-op.c
>> @@ -73,55 +73,42 @@ void (*pv_post_outb_hook)(unsigned int p
>>
>> typedef void io_emul_stub_t(struct cpu_user_regs *);
>>
>> -void __x86
flight 119239 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119239/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-build fail in 119177 REGR. vs. 119036
Tests which are f
On Thu, Feb 15, 2018 at 06:57:46PM +, Andrew Cooper wrote:
> On 15/02/18 16:25, Roger Pau Monne wrote:
> > There a bunch of bits in CR4 that should be allowed to be set directly
> > by the guest without requiring Xen intervention, currently this is
> > already done by passing through guest writ
The emulation layers of Xen lack PCID support, and as we only offer
PCID to HAP guests, all writes to CR3 are handled by hardware,
except when introspection is involved. Consequently, trying to set
CR3 when the noflush bit is set in hvm_set_cr3() leads to domain
crashes. The workaround is to clear
(Moving that to xen-devel + Stefano)
On 16/02/18 09:23, Iain Hunter wrote:
Hi Julian,
Hi,
The patch I applied is below. I have no idea if it is AM572x/DRA7xx
specific or just specific to the 2017.01 u-boot I was using.
Thank you for sending the patch. Indeed we don't know the state of the
On Thu, 2018-02-15 at 06:33 -0700, Jan Beulich wrote:
> > > > On 08.02.18 at 11:23, wrote:
> >
> > --- a/xen/arch/x86/cpu/common.c
> > +++ b/xen/arch/x86/cpu/common.c
> > @@ -118,9 +118,18 @@ void (* __read_mostly ctxt_switch_masking)(const
> > struct vcpu *next);
> >
> > bool __init probe_cp
The new shim tests uses the same approach as the PVH one, but doesn't
differentiate between AMD and Intel.
This is the (trimmed) diff of the output from mg-show-flight-runvars:
+test-amd64-amd64-xl-pvshimall_host_di_version2017-12-14
+test-amd64-i386-xl-pvshim all_host_di_version2
On Fri, 16 Feb 2018 09:05:02 +0100
Yessine Daoud wrote:
>Hello,
>
>Please find attached the requested log file.
According to the log, string I/O is actually passed from IOREQ buffered
-- in groups of 4096 I/O read ops, but they're still emulated one by
one, calling QEMU's fw_cfg emulation for ev
Hi Stefano,
On 15/02/18 23:16, Stefano Stabellini wrote:
On big.LITTLE systems not all cores have the same ACTLR. Instead of
reading ACTLR and setting v->arch.actlr in vcpu_initialise, which is run
always on pcpu 0, do it later on the same pcpu where the vcpu will run.
While the Hardware domai
Hi Stefano,
On 15/02/18 23:16, Stefano Stabellini wrote:
On big.LITTLE systems not all cores have the same midr. Instead of
initializing the vpidr to the boot cpu midr, set it to the value of the
midr of the pcpu where the vcpu will run.
This way, assuming that the vcpu has been created with th
>>> On 16.02.18 at 11:33, wrote:
> On Thu, 2018-02-15 at 06:33 -0700, Jan Beulich wrote:
>> > > > On 08.02.18 at 11:23, wrote:
>> >uint64_t val;
>> > + int rc;
>> >
>> > - if (rdmsr_safe(MSR_INTEL_PLATFORM_INFO, val) ||
>> > + if ((rc = rdmsr_safe(MSR_INTEL_PLATFORM_INFO, val)) == 0)
>>
flight 119251 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119251/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt broken
build-armhf-libvirt 4 host-i
>>> On 16.02.18 at 11:22, wrote:
> The emulation layers of Xen lack PCID support, and as we only offer
> PCID to HAP guests, all writes to CR3 are handled by hardware,
> except when introspection is involved. Consequently, trying to set
> CR3 when the noflush bit is set in hvm_set_cr3() leads to d
Hi Stefano,
On 15/02/18 23:17, Stefano Stabellini wrote:
Update the documentation of the hmp-unsafe option to explain how to use
it safely, together with the right cpu affinity setting, on big.LITTLE
systems.
Also update the warning message to point users to the docs.
Signed-off-by: Stefano St
On Thu, Feb 15, 2018 at 09:32:00PM +0200, Razvan Cojocaru wrote:
> On 02/15/2018 08:57 PM, Andrew Cooper wrote:
> > On 15/02/18 16:25, Roger Pau Monne wrote:
> >> There a bunch of bits in CR4 that should be allowed to be set directly
> >> by the guest without requiring Xen intervention, currently t
On Fri, 2018-02-16 at 04:06 -0700, Jan Beulich wrote:
> > > > On 16.02.18 at 11:33, wrote:
> >
> > On Thu, 2018-02-15 at 06:33 -0700, Jan Beulich wrote:
> > > > > > On 08.02.18 at 11:23, wrote:
> > > >
> > > > uint64_t val;
> > > > + int rc;
> > > >
> > > > - if (rdmsr_saf
>>> On 16.02.18 at 12:31, wrote:
> On Fri, 2018-02-16 at 04:06 -0700, Jan Beulich wrote:
>> > > > On 16.02.18 at 11:33, wrote:
>> >
>> > On Thu, 2018-02-15 at 06:33 -0700, Jan Beulich wrote:
>> > > > > > On 08.02.18 at 11:23, wrote:
>> > > >
>> > > >uint64_t val;
>> > > > + int rc
On 16/02/18 11:31, Sergey Dyasli wrote:
> On Fri, 2018-02-16 at 04:06 -0700, Jan Beulich wrote:
> On 16.02.18 at 11:33, wrote:
>>> On Thu, 2018-02-15 at 06:33 -0700, Jan Beulich wrote:
>>> On 08.02.18 at 11:23, wrote:
> uint64_t val;
> + int rc;
>
> - if (rdmsr_safe(MS
Hi Rupal,
I CC'ed two lists and the mentors of projects. Thank you for your interest in
the projects.
> I went through
> https://www.outreachy.org/2018-may-august/communities/xen-project/
> project page and could see that each of these two projects has their own set
> of mentors
> (2 each, o
On 02/16/2018 01:25 PM, Roger Pau Monné wrote:
> On Thu, Feb 15, 2018 at 09:32:00PM +0200, Razvan Cojocaru wrote:
>> On 02/15/2018 08:57 PM, Andrew Cooper wrote:
>>> On 15/02/18 16:25, Roger Pau Monne wrote:
There a bunch of bits in CR4 that should be allowed to be set directly
by the gue
On 15/02/18 23:16, Stefano Stabellini wrote:
Hi all,
Hi Stefano,
This series changes the initialization of two virtual registers to make
sure they match the value of the underlying physical cpu.
It also disables cpus different from the boot cpu, unless a newly
introduced command line optio
Hello,
Following two-patch series optimize CR4 access for vmx/hap.
I couldn't figure out a similar approach for AMD, since according to
section 15.9 (Instruction Intercepts), you either intercept all access
to CR4 or none. In any case a similar optimization for AMD can always be
added later.
Tha
At the moment this is currently set at VMCS creation and not changed,
but further patches are going to change the CR4 mask at runtime.
Signed-off-by: Roger Pau Monné
---
Cc: Boris Ostrovsky
Cc: Suravee Suthikulpanit
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Jun Nakajima
Cc: Kevin Tian
---
Chang
There a bunch of bits in CR4 that should be allowed to be set directly
by the guest without requiring Xen intervention, currently this is
already done by passing through guest writes into the CR4 used when
running in non-root mode, but taking an expensive vmexit in order to
do so.
xenalyze reports
Previous usage is not correct and would prevent certain updates from
being notified to the monitor client.
For example if (value ^ old) == (PGE | PSE) and mask == PGE this
update would not be notified.
Signed-off-by: Roger Pau Monné
---
Cc: Razvan Cojocaru
Cc: Tamas K Lengyel
Cc: Jan Beulich
On 02/16/2018 02:18 PM, Roger Pau Monne wrote:
> Previous usage is not correct and would prevent certain updates from
> being notified to the monitor client.
>
> For example if (value ^ old) == (PGE | PSE) and mask == PGE this
> update would not be notified.
>
> Signed-off-by: Roger Pau Monné
>
On 02/16/2018 02:10 PM, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
> index f229e69948..4317658c56 100644
> --- a/xen/arch/x86/monitor.c
> +++ b/xen/arch/x86/monitor.c
> @@ -189,10 +189,11 @@ int arch_monitor_domctl_event(struct domain *d,
> ad
On Fri, Feb 16, 2018 at 02:30:55PM +0200, Razvan Cojocaru wrote:
> On 02/16/2018 02:10 PM, Roger Pau Monne wrote:
> > diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
> > index f229e69948..4317658c56 100644
> > --- a/xen/arch/x86/monitor.c
> > +++ b/xen/arch/x86/monitor.c
> > @@ -189,10
On 02/16/2018 02:37 PM, Roger Pau Monné wrote:
> On Fri, Feb 16, 2018 at 02:30:55PM +0200, Razvan Cojocaru wrote:
>> On 02/16/2018 02:10 PM, Roger Pau Monne wrote:
>>> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
>>> index f229e69948..4317658c56 100644
>>> --- a/xen/arch/x86/monitor
On 16/02/18 12:10, Roger Pau Monne wrote:
> diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
> index d93166fb92..811d4c10ae 100644
> --- a/xen/include/asm-x86/hvm/vcpu.h
> +++ b/xen/include/asm-x86/hvm/vcpu.h
> @@ -156,6 +156,9 @@ struct hvm_vcpu {
> */
> unsi
On 16/02/18 13:19, Peter Lawthers wrote:
> From: Uwe Dannowski
>
> Errors on updating the microcode in the processor were silently
> dropped when invoked via the microcode_update hypercall. Also, the log
> message was misleading.
>
> Signed-off-by: Uwe Dannowski
> Reviewed-by: Stefan Nuernberger
From: Uwe Dannowski
Errors on updating the microcode in the processor were silently
dropped when invoked via the microcode_update hypercall. Also, the log
message was misleading.
Signed-off-by: Uwe Dannowski
Reviewed-by: Stefan Nuernberger
Reviewed-by: Martin Pohlack
CC: David Woodhouse
CC:
On Fr, 2018-02-16 at 13:19 +, Peter Lawthers wrote:
> From: Uwe Dannowski
>
> Errors on updating the microcode in the processor were silently
> dropped when invoked via the microcode_update hypercall. Also, the
> log
> message was misleading.
>
> Signed-off-by: Uwe Dannowski
> Reviewed-by
Commit f7f99100d8d95dbcf09e0216a143211e79418b9f ("mm: stop zeroing
memory during allocation in vmemmap") broke Xen pv domains in some
configurations, as the "Pinned" information in struct page of early
page tables could get lost.
Avoid this problem by not deferring struct page initialization when
[CC Pavel]
On Fri 16-02-18 14:37:26, Juergen Gross wrote:
> Commit f7f99100d8d95dbcf09e0216a143211e79418b9f ("mm: stop zeroing
> memory during allocation in vmemmap") broke Xen pv domains in some
> configurations, as the "Pinned" information in struct page of early
> page tables could get lost.
C
On 16/02/18 14:59, Michal Hocko wrote:
> [CC Pavel]
>
> On Fri 16-02-18 14:37:26, Juergen Gross wrote:
>> Commit f7f99100d8d95dbcf09e0216a143211e79418b9f ("mm: stop zeroing
>> memory during allocation in vmemmap") broke Xen pv domains in some
>> configurations, as the "Pinned" information in struc
On Fri 16-02-18 15:02:17, Juergen Gross wrote:
> On 16/02/18 14:59, Michal Hocko wrote:
> > [CC Pavel]
> >
> > On Fri 16-02-18 14:37:26, Juergen Gross wrote:
> >> Commit f7f99100d8d95dbcf09e0216a143211e79418b9f ("mm: stop zeroing
> >> memory during allocation in vmemmap") broke Xen pv domains in s
The vGIC relies on having a pending_irq available for every IRQs
described in the ranks. As each rank describes 32 interrupts, we need to
make sure the number of SPIs is a multiple of 32.
Reported-by: Jarvis Roach
Signed-off-by: Julien Grall
---
Jarvis, I don't have Jeff's e-mail address so
(+ Jarvis)
Hmmm it looks like my modification in git-send-email to take CC all *-by
tags disappeared. So CC jarvis.
Cheers,
On 16/02/18 14:35, Julien Grall wrote:
The vGIC relies on having a pending_irq available for every IRQs
described in the ranks. As each rank describes 32 interrupts, we
flight 119273 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119273/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-xtf-amd64-amd64-2 49 xtf/test-hvm64-lbr-tsx-vmentry fail like 118818
test-xtf-amd64-amd64-3 49 xt
The vGIC relies on having a pending_irq available for every IRQs
described in the ranks. As each rank describes 32 interrupts, we need to
make sure the number of SPIs is a multiple of 32.
Reported-by: Jeff Kubascik
Signed-off-by: Julien Grall
Cc: Jarvis Roach
---
This should be backported
On 02/16/2018 02:39 PM, Razvan Cojocaru wrote:
> On 02/16/2018 02:37 PM, Roger Pau Monné wrote:
>> On Fri, Feb 16, 2018 at 02:30:55PM +0200, Razvan Cojocaru wrote:
>>> On 02/16/2018 02:10 PM, Roger Pau Monne wrote:
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index f229e69
On 13/02/18 15:01, Andre Przywara wrote:
Hi,
Hi Andre,
On 13/02/18 12:02, Julien Grall wrote:
On 12/02/18 17:53, Andre Przywara wrote:
Hi,
Hi Andre,
On 12/02/18 13:55, Julien Grall wrote:
Hi Andre,
On 09/02/18 14:39, Andre Przywara wrote:
When playing around with hardware mapped, l
I've just had to deal with an early boot crash of Linux which occurred
so early that even "earlyprintk=xen" did not produce any useful output.
Hence the domain appeared to hang, while in fact it had brought down its
only vCPU. By translating this to a shutdown, the situation will be
better recogniz
On 13/02/18 11:18, Andre Przywara wrote:
Hi,
Hi Andre,
On 12/02/18 17:42, Julien Grall wrote:
Hi Andre,
On 09/02/18 14:39, Andre Przywara wrote:
The new VGIC implementation centers around a struct vgic_irq instance
per virtual IRQ.
Provide a function to retrieve the right instance for a
On 16/02/18 15:10, Jan Beulich wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1321,6 +1321,22 @@ long do_vcpu_op(int cmd, unsigned int vc
> break;
>
> case VCPUOP_down:
> +for_each_vcpu ( d, v )
> +if ( v->vcpu_id != vcpuid && !test_bit(_VPF
Commit f7f99100d8d95dbcf09e0216a143211e79418b9f ("mm: stop zeroing
memory during allocation in vmemmap") broke Xen pv domains in some
configurations, as the "Pinned" information in struct page of early
page tables could get lost. This will lead to the kernel trying to
write directly into the page t
On 13/02/18 15:40, Andre Przywara wrote:
Hi,
On 13/02/18 12:41, Julien Grall wrote:
Hi Andre,
On 09/02/18 14:39, Andre Przywara wrote:
gets called on guest entry and exit.
The code talking to the actual GICv2/v3 hardware is added in the
following patches.
This is based on Linux commit 0919
Hi Andre,
On 13/02/18 18:17, Andre Przywara wrote:
On 13/02/18 16:52, Julien Grall wrote:
+struct vgic_register_region {
+ unsigned int reg_offset;
+ unsigned int len;
+ unsigned int bits_per_irq;
+ unsigned int access_flags;
+ union
+ {
+ unsigned long (*read)(struct v
Since both kernel and user mode run in ring 3, they run in the same
"predictor mode". While the kernel could take care of this itself, doing
so would be yet another item distinguishing PV from native. Additionally
we're in a much better position to issue the barrier command, and we can
save a #GP (
Hi Andre,
On 09/02/18 14:39, Andre Przywara wrote:
Create vgic-mmio-v2.c to describe GICv2 emulation specific handlers
using the initializer macros provided by the VGIC MMIO framework.
Provide a function to register the GICv2 distributor registers to
the Xen MMIO framework.
The actual handler fu
Commit f7f99100d8d95dbcf09e0216a143211e79418b9f ("mm: stop zeroing
memory during allocation in vmemmap") broke Xen pv domains in some
configurations, as the "Pinned" information in struct page of early
page tables could get lost. This will lead to the kernel trying to
write directly into the page t
On 16/02/18 08:00, Jan Beulich wrote:
On 15.02.18 at 17:53, wrote:
>> On 15/02/18 16:03, Jan Beulich wrote:
>>> --- a/xen/arch/x86/pv/emul-priv-op.c
>>> +++ b/xen/arch/x86/pv/emul-priv-op.c
>>> @@ -73,55 +73,42 @@ void (*pv_post_outb_hook)(unsigned int p
>>>
>>> typedef void io_emul_stub_t
On Fri, Feb 16, 2018 at 08:10:48AM -0700, Jan Beulich wrote:
> I've just had to deal with an early boot crash of Linux which occurred
> so early that even "earlyprintk=xen" did not produce any useful output.
> Hence the domain appeared to hang, while in fact it had brought down its
> only vCPU. By
Hi,
On 09/02/18 14:39, Andre Przywara wrote:
Those three registers are v2 emulation specific, so their implementation
lives entirely in vgic-mmio-v2.c. Also they are handled in one function,
as their implementation is pretty simple.
When the guest enables the distributor, we kick all VCPUs to ge
On Fri, Feb 16, 2018 at 03:52:48PM +, Roger Pau Monné wrote:
> On Fri, Feb 16, 2018 at 08:10:48AM -0700, Jan Beulich wrote:
> > I've just had to deal with an early boot crash of Linux which occurred
> > so early that even "earlyprintk=xen" did not produce any useful output.
> > Hence the domain
On Fri, 2018-02-16 at 11:38 +, Andrew Cooper wrote:
> On 16/02/18 11:31, Sergey Dyasli wrote:
> > On Fri, 2018-02-16 at 04:06 -0700, Jan Beulich wrote:
> > > > > > On 16.02.18 at 11:33, wrote:
> > > >
> > > > On Thu, 2018-02-15 at 06:33 -0700, Jan Beulich wrote:
> > > > > > > > On 08.02.18 at
On 16/02/18 16:00, Sergey Dyasli wrote:
> On Fri, 2018-02-16 at 11:38 +, Andrew Cooper wrote:
>> On 16/02/18 11:31, Sergey Dyasli wrote:
>>> On Fri, 2018-02-16 at 04:06 -0700, Jan Beulich wrote:
>>> On 16.02.18 at 11:33, wrote:
> On Thu, 2018-02-15 at 06:33 -0700, Jan Beulich wrote:
>>
On Fri, Feb 16, 2018 at 03:59:45PM +, Wei Liu wrote:
> On Fri, Feb 16, 2018 at 03:52:48PM +, Roger Pau Monné wrote:
> > On Fri, Feb 16, 2018 at 08:10:48AM -0700, Jan Beulich wrote:
> > > I've just had to deal with an early boot crash of Linux which occurred
> > > so early that even "earlypr
>>> On 16.02.18 at 16:50, wrote:
> On 16/02/18 08:00, Jan Beulich wrote:
> On 15.02.18 at 17:53, wrote:
>>> On 15/02/18 16:03, Jan Beulich wrote:
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -73,55 +73,42 @@ void (*pv_post_outb_hook)(unsigned int
>>> On 16.02.18 at 16:52, wrote:
> On Fri, Feb 16, 2018 at 08:10:48AM -0700, Jan Beulich wrote:
>> I've just had to deal with an early boot crash of Linux which occurred
>> so early that even "earlyprintk=xen" did not produce any useful output.
>> Hence the domain appeared to hang, while in fact i
On 16/02/18 17:25, Jan Beulich wrote:
On 16.02.18 at 16:52, wrote:
>> On Fri, Feb 16, 2018 at 08:10:48AM -0700, Jan Beulich wrote:
>>> I've just had to deal with an early boot crash of Linux which occurred
>>> so early that even "earlyprintk=xen" did not produce any useful output.
>>> Hence t
Hi Andre,
On 09/02/18 14:39, Andre Przywara wrote:
As the enable register handlers are shared between the v2 and v3
emulation, their implementation goes into vgic-mmio.c, to be easily
referenced from the v3 emulation as well later.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic/vgic-mmi
On 16/02/18 16:21, Jan Beulich wrote:
On 16.02.18 at 16:50, wrote:
>> On 16/02/18 08:00, Jan Beulich wrote:
>> On 15.02.18 at 17:53, wrote:
On 15/02/18 16:03, Jan Beulich wrote:
> --- a/xen/arch/x86/pv/emul-priv-op.c
> +++ b/xen/arch/x86/pv/emul-priv-op.c
> @@ -73,55 +73
On 16/02/18 15:39, Jan Beulich wrote:
> Since both kernel and user mode run in ring 3, they run in the same
> "predictor mode". While the kernel could take care of this itself, doing
> so would be yet another item distinguishing PV from native. Additionally
> we're in a much better position to issu
Hi Andre,
On 09/02/18 14:39, Andre Przywara wrote:
The pending register handlers are shared between the v2 and v3
emulation, so their implementation goes into vgic-mmio.c, to be easily
referenced from the v3 emulation as well later.
For level triggered interrupts the real line level is unaffecte
Hi Andre,
On 09/02/18 14:39, Andre Przywara wrote:
The active register handlers are shared between the v2 and v3 emulation,
so their implementation goes into vgic-mmio.c, to be easily referenced
from the v3 emulation as well later.
Since activation/deactivation of an interrupt may happen entirel
With gcc 7.3.0, the build fails like this:
src/xenstat_linux.c: In function ‘getBridge’
src/xenstat_linux.c:78:34: warning: ‘%s’ directive writing up to 255 bytes into
a region of size 241 [-Wformat-overflow=]
sprintf(tmp, "/sys/class/net/%s/bridge", de->d_name);
Hi Andre,
On 09/02/18 14:39, Andre Przywara wrote:
The priority register handlers are shared between the v2 and v3 emulation,
so their implementation goes into vgic-mmio.c, to be easily referenced
from the v3 emulation as well later.
There is a corner case when we change the priority of a pendin
On 16/02/18 17:36, Dario Faggioli wrote:
> With gcc 7.3.0, the build fails like this:
>
> src/xenstat_linux.c: In function ‘getBridge’
> src/xenstat_linux.c:78:34: warning: ‘%s’ directive writing up to 255 bytes
> into a region of size 241 [-Wformat-overflow=]
> sprintf(tmp, "/sys/class/net/%
On 02/16/2018 09:02 AM, Juergen Gross wrote:
On 16/02/18 14:59, Michal Hocko wrote:
[CC Pavel]
On Fri 16-02-18 14:37:26, Juergen Gross wrote:
Commit f7f99100d8d95dbcf09e0216a143211e79418b9f ("mm: stop zeroing
memory during allocation in vmemmap") broke Xen pv domains in some
configurations, as
On Fri, Feb 16, 2018 at 06:36:51PM +0100, Dario Faggioli wrote:
> With gcc 7.3.0, the build fails like this:
>
> src/xenstat_linux.c: In function ‘getBridge’
> src/xenstat_linux.c:78:34: warning: ‘%s’ directive writing up to 255 bytes
> into a region of size 241 [-Wformat-overflow=]
> sprint
On Fri, Feb 16, 2018 at 05:44:05PM +, Wei Liu wrote:
> On Fri, Feb 16, 2018 at 06:36:51PM +0100, Dario Faggioli wrote:
> > With gcc 7.3.0, the build fails like this:
> >
> > src/xenstat_linux.c: In function ‘getBridge’
> > src/xenstat_linux.c:78:34: warning: ‘%s’ directive writing up to 255 by
We're noticing a reproducible system boot hang on certain
post-Skylake platforms where the BIOS is configured in
legacy boot mode with x2APIC disabled. The system stalls
immediately after writing the first SMP initialization
sequence into APIC ICR.
The cause of the problem is watchdog NMI handler
Hi,
As in the subject, the guest crashes on boot, before kernel output
anything. I've isolated this to the conditions below:
- PV guest have PCI device assigned (e1000e emulated by QEMU in this case),
without PCI device it works
- Xen (in KVM) is started through OVMF; with seabios it works
-
On 16/02/18 17:48, Marek Marczykowski-Górecki wrote:
> Hi,
>
> As in the subject, the guest crashes on boot, before kernel output
> anything. I've isolated this to the conditions below:
> - PV guest have PCI device assigned (e1000e emulated by QEMU in this case),
>without PCI device it works
>
On Fri, 2018-02-16 at 17:44 +, Wei Liu wrote:
> On Fri, Feb 16, 2018 at 06:36:51PM +0100, Dario Faggioli wrote:
> >
> > --- a/tools/xenstat/libxenstat/src/xenstat_linux.c
> > +++ b/tools/xenstat/libxenstat/src/xenstat_linux.c
> > @@ -69,18 +69,20 @@ void getBridge(char *excludeName, char *resu
On Fri, 2018-02-16 at 17:44 +, Wei Liu wrote:
> On Fri, Feb 16, 2018 at 06:36:51PM +0100, Dario Faggioli wrote:
> >
> > --- a/tools/xenstat/libxenstat/src/xenstat_linux.c
> > +++ b/tools/xenstat/libxenstat/src/xenstat_linux.c
> > @@ -69,18 +69,20 @@ void getBridge(char *excludeName, char *resu
On Fri, Feb 16, 2018 at 06:55:08PM +0100, Dario Faggioli wrote:
> On Fri, 2018-02-16 at 17:44 +, Wei Liu wrote:
> > On Fri, Feb 16, 2018 at 06:36:51PM +0100, Dario Faggioli wrote:
> > >
> > > --- a/tools/xenstat/libxenstat/src/xenstat_linux.c
> > > +++ b/tools/xenstat/libxenstat/src/xenstat_li
On Fri, 2018-02-16 at 17:58 +, Wei Liu wrote:
> On Fri, Feb 16, 2018 at 06:55:08PM +0100, Dario Faggioli wrote:
> > On Fri, 2018-02-16 at 17:44 +, Wei Liu wrote:
> > >
> > Right! And what do I do if it fails, 'continue' the while(), I
> > guess?
> >
>
> Looking at the error message again
flight 119373 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119373/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
On Mon, 2018-02-12 at 20:44 +0200, Andrii Anisov wrote:
> Dario,
>
Hi,
> On 12.02.18 12:20, Andrii Anisov wrote:
> > Actually as per Meng's explanation and calculations the problem was
> > on
> > my side - wrong DomR task/VCPU parameters.
> > I was running the system with dummy loads and values
With gcc 7.3.0, the build fails like this:
src/xenstat_linux.c: In function ‘getBridge’
src/xenstat_linux.c:78:34: warning: ‘%s’ directive writing up to 255 bytes into
a region of size 241 [-Wformat-overflow=]
sprintf(tmp, "/sys/class/net/%s/bridge", de->d_name);
On Fri, Feb 16, 2018 at 07:38:48PM +0100, Dario Faggioli wrote:
> With gcc 7.3.0, the build fails like this:
>
> src/xenstat_linux.c: In function ‘getBridge’
> src/xenstat_linux.c:78:34: warning: ‘%s’ directive writing up to 255 bytes
> into a region of size 241 [-Wformat-overflow=]
> sprint
On Fri, Feb 16, 2018 at 05:52:50PM +, Andrew Cooper wrote:
> On 16/02/18 17:48, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > As in the subject, the guest crashes on boot, before kernel output
> > anything. I've isolated this to the conditions below:
> > - PV guest have PCI device assigned
On 16/02/18 18:51, Marek Marczykowski-Górecki wrote:
> On Fri, Feb 16, 2018 at 05:52:50PM +, Andrew Cooper wrote:
>> On 16/02/18 17:48, Marek Marczykowski-Górecki wrote:
>>> Hi,
>>>
>>> As in the subject, the guest crashes on boot, before kernel output
>>> anything. I've isolated this to the co
On Fri, Feb 16, 2018 at 07:02:39PM +, Andrew Cooper wrote:
> On 16/02/18 18:51, Marek Marczykowski-Górecki wrote:
> > On Fri, Feb 16, 2018 at 05:52:50PM +, Andrew Cooper wrote:
> >> On 16/02/18 17:48, Marek Marczykowski-Górecki wrote:
> >>> Hi,
> >>>
> >>> As in the subject, the guest crash
On Fri, 16 Feb 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 15/02/18 23:16, Stefano Stabellini wrote:
> > On big.LITTLE systems not all cores have the same midr. Instead of
> > initializing the vpidr to the boot cpu midr, set it to the value of the
> > midr of the pcpu where the vcpu will run.
>
On Fri, 16 Feb 2018 16:41:01 +0100 Juergen Gross wrote:
> Commit f7f99100d8d95dbcf09e0216a143211e79418b9f ("mm: stop zeroing
> memory during allocation in vmemmap") broke Xen pv domains in some
> configurations, as the "Pinned" information in struct page of early
> page tables could get lost. Thi
On Fri, 16 Feb 2018 16:41:01 +0100 Juergen Gross wrote:
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -347,6 +347,9 @@ static inline bool update_defer_init(pg_data_t *pgdat,
> /* Always populate low zones for address-constrained allocations */
> if (zone_end < pgdat_end_pfn(pgd
On 16/02/2018 20:31, Stefano Stabellini wrote:
On Fri, 16 Feb 2018, Julien Grall wrote:
Hi Stefano,
On 15/02/18 23:16, Stefano Stabellini wrote:
On big.LITTLE systems not all cores have the same midr. Instead of
initializing the vpidr to the boot cpu midr, set it to the value of the
midr of
On Fri, 16 Feb 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 15/02/18 23:17, Stefano Stabellini wrote:
> > Update the documentation of the hmp-unsafe option to explain how to use
> > it safely, together with the right cpu affinity setting, on big.LITTLE
> > systems.
> >
> > Also update the warni
flight 119350 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119350/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 118324
test-amd64-i386-xl-
On Fri, 16 Feb 2018, Julien Grall wrote:
> On 16/02/2018 20:31, Stefano Stabellini wrote:
> > On Fri, 16 Feb 2018, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 15/02/18 23:16, Stefano Stabellini wrote:
> > > > On big.LITTLE systems not all cores have the same midr. Instead of
> > > > initi
On 16/02/2018 20:50, Stefano Stabellini wrote:
On Fri, 16 Feb 2018, Julien Grall wrote:
Hi Stefano,
On 15/02/18 23:17, Stefano Stabellini wrote:
Update the documentation of the hmp-unsafe option to explain how to use
it safely, together with the right cpu affinity setting, on big.LITTLE
syst
Hi Stefano,
On 16/02/2018 20:59, Stefano Stabellini wrote:
On Fri, 16 Feb 2018, Julien Grall wrote:
On 16/02/2018 20:31, Stefano Stabellini wrote:
On Fri, 16 Feb 2018, Julien Grall wrote:
Hi Stefano,
On 15/02/18 23:16, Stefano Stabellini wrote:
On big.LITTLE systems not all cores have the s
On Fri, 16 Feb 2018, Julien Grall wrote:
> On 16/02/2018 20:50, Stefano Stabellini wrote:
> > On Fri, 16 Feb 2018, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 15/02/18 23:17, Stefano Stabellini wrote:
> > > > Update the documentation of the hmp-unsafe option to explain how to use
> > > >
On Wed, Jan 24, 2018 at 03:18:48PM +0100, Marek Marczykowski-Górecki wrote:
> Allow updating those two adjacent 32bit fields with one 64bit write.
> This fixes qemu crash when booting Xen inside.
>
> See discussion on Xen side of the thing here:
> http://xen.markmail.org/message/6mrmemrnmhxvaxba
On Fri, 16 Feb 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 16/02/2018 20:59, Stefano Stabellini wrote:
> > On Fri, 16 Feb 2018, Julien Grall wrote:
> > > On 16/02/2018 20:31, Stefano Stabellini wrote:
> > > > On Fri, 16 Feb 2018, Julien Grall wrote:
> > > > > Hi Stefano,
> > > > >
> > > > > On
On Feb 16, 2018, at 14:02, Andrew Cooper wrote:
>
> IMO, PCI Passthrough is a trainwreck, and it is a miracle it functions
> at all.
Would that statement apply to other hypervisors like KVM, VMware ESX or
Hyper-V, i.e. are the deficiencies in PCI devices/firmware, IOMMUs, platform
firmware?
1 - 100 of 113 matches
Mail list logo
