flight 119386 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119386/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 119036
test-armhf-armhf-libvirt-xsm 14 sav
On Fri, 16 Feb 2018 17:46:48 +
Igor Druzhinin wrote:
>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 i
flight 119370 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119370/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-armhf-pvops 5 host-build-pre
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-win7-amd64
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditi
flight 119427 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119427/
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 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 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
flight 119358 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119358/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 118698
Regressions which
On Fri, 16 Feb 2018, Julien Grall wrote:
> On 16/02/2018 21:15, Stefano Stabellini wrote:
> > 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,
flight 119436 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119436/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 119433 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119433/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-xtf-amd64-amd64-3 52 xtf/test-hvm64-memop-seg fail never pass
test-xtf-amd64-amd64-4 52 xtf/test-hvm6
On Fri, 16 Feb 2018, Julien Grall wrote:
> 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
On 16/02/2018 21:15, Stefano Stabellini wrote:
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 expl
Hi Stefano,
On 16/02/2018 21:34, Stefano Stabellini wrote:
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
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?
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 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:
> 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
> > > >
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 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
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
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:
> 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
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 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 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, 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, 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 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 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 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
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 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
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 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
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: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 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
>
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
-
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
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
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 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 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/%
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
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 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
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
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
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
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 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
>>> 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 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 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 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, 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 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
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 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
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
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
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
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 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
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
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 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
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
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 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
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
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
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
(+ 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
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
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
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
[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
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
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
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 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
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 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 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: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 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é
>
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
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
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
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
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
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 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
>>> 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 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 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
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
1 - 100 of 113 matches
Mail list logo
