flight 148949 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148949/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
133580
Regressions
flight 148952 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148952/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
148666
Tests which did
flight 148937 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148937/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 14486
flight 148983 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148983/
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
On Mar 24, 2020, at 14:03, George Dunlap wrote:
>
> I wanted to let everyone know that the XenProject is moving forward with
> plans to hold XenSummit this year, one way or another.
>
> There are two basic approaches the Advisory Board has been considering:
> Postponing the even until later
On 24/03/2020 15:21, Hongyan Xia wrote:
From: Hongyan Xia
Unfortunately, even though that commit dropped the domctl lock and
allowed other domctl to continue, it created severe lock contention
within domain destructions themselves. Multiple domain destructions in
parallel now spin for the gl
On 24/03/2020 16:13, Jan Beulich wrote:
On 24.03.2020 16:21, Hongyan Xia wrote:
From: Hongyan Xia
In contrast,
after dropping that commit, parallel domain destructions will just fail
to take the domctl lock, creating a hypercall continuation and backing
off immediately, allowing the thread t
Hi David,
On 24/03/2020 17:55, David Woodhouse wrote:
On Tue, 2020-03-24 at 10:08 +, Julien Grall wrote:
Hi David,
On 23/03/2020 10:55, David Woodhouse wrote:
On Mon, 2020-03-23 at 09:34 +, Julien Grall wrote:
For liveupdate, we will need a way to initialize a page but mark it as
I wanted to let everyone know that the XenProject is moving forward with plans
to hold XenSummit this year, one way or another.
There are two basic approaches the Advisory Board has been considering:
Postponing the even until later in the year, or holding a virtual event during
the same timefr
On Tue, 2020-03-24 at 10:08 +, Julien Grall wrote:
> Hi David,
>
> On 23/03/2020 10:55, David Woodhouse wrote:
> > On Mon, 2020-03-23 at 09:34 +, Julien Grall wrote:
> > > For liveupdate, we will need a way to initialize a page but mark it as
> > > already inuse (i.e in the same state as t
On Mon, Mar 23, 2020 at 04:11:53PM +0100, Roger Pau Monné wrote:
> On Thu, Mar 19, 2020 at 04:24:12PM +, Anthony PERARD wrote:
> > So, testing for the -Wa,--strip-local-absolute flags turns out to be
> > more complicated than I though it would be.
> > - cc-option-add doesn't work because it do
This is to augment SYSCALL, which has been supported for quite some
time.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -5975,6 +5975,60 @@ x86_emulate(
goto done;
break;
+case X86EMUL_OPC(0x0f,
AMD CPUs permit the insn everywhere (even outside of protected mode),
while Intel ones restrict it to 64-bit mode. While at it also add the
so far missing CPUID bit check.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -187
Intel CPUs permit both insns there while AMD ones don't.
While at it also
- drop the ring 0 check from SYSENTER handling - neither Intel's nor
AMD's insn pages have any indication of #GP(0) getting raised when
executed from ring 0, and trying it out in practice also confirms
the check should
Intel CPUs ignore operand size overrides here, while AMD ones don't.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -813,6 +813,17 @@ static const struct {
.opcode = { 0x66, 0x67, 0xe3, 0x10 },
Intel CPUs ignore operand size overrides here, while AMD ones don't.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -757,6 +757,62 @@ static const struct {
.opc_len = { 4, 4 },
.stkoff = { 2 +
These are to aid readbility at their use sites, in particular because
we're going to gain more of them.
Suggested-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1836,6 +1836,18 @@ in_protmode(
retur
Intel CPUs ignore operand size overrides here, while AMD ones don't.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -733,6 +733,34 @@ static struct x86_emulate_ops emulops =
#define EFLAGS_ALWAYS_SET (X86_EFLAG
There are quite a few more vendor differences than we currently support,
in particular in 64-bit mode. Now that I've made some progress on the
binutils side I felt more confident in making the changes here as well.
1: add wrappers to check for AMD-like behavior
2: vendor specific near RET behavior
flight 148925 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148925/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-dom0pvh-xl-intel 17 guest-saverestore.2 fail pass in 148873
test-arm64-arm64-xl 12
On 24.03.2020 16:21, Hongyan Xia wrote:
> From: Hongyan Xia
>
> Unfortunately, even though that commit dropped the domctl lock and
> allowed other domctl to continue, it created severe lock contention
> within domain destructions themselves. Multiple domain destructions in
> parallel now spin for
flight 148954 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148954/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
flight 148946 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148946/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2f524a745e23e1b4c73ea22b058492bfe4af84c2
baseline version:
ovmf 0c8ea9fe1adbbee230ee0
From: Hongyan Xia
Unfortunately, even though that commit dropped the domctl lock and
allowed other domctl to continue, it created severe lock contention
within domain destructions themselves. Multiple domain destructions in
parallel now spin for the global heap lock when freeing memory and could
On 24.03.20 16:18, Roger Pau Monné wrote:
On Tue, Mar 24, 2020 at 04:13:48PM +0100, Jürgen Groß wrote:
On 24.03.20 16:00, Roger Pau Monne wrote:
To mention it's also useful for PVH or HVM domains that require
mapping foreign memory or grants.
Signed-off-by: Roger Pau Monné
---
Cc: Boris Ostro
On Tue, Mar 24, 2020 at 04:13:48PM +0100, Jürgen Groß wrote:
> On 24.03.20 16:00, Roger Pau Monne wrote:
> > To mention it's also useful for PVH or HVM domains that require
> > mapping foreign memory or grants.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
> > Cc: Boris Ostrovsky
> > Cc: Juerge
On Tue, Mar 24, 2020 at 04:09:35PM +0100, Jürgen Groß wrote:
> On 24.03.20 16:00, Roger Pau Monne wrote:
> > Without it a PVH dom0 is mostly useless, as it would balloon down huge
> > amounts of RAM in order get physical address space to map foreign
> > memory and grants, ultimately leading to an o
On 24.03.20 16:00, Roger Pau Monne wrote:
To mention it's also useful for PVH or HVM domains that require
mapping foreign memory or grants.
Signed-off-by: Roger Pau Monné
---
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-devel@lists.xenproject.org
---
drivers/xen/Kco
On Tue, 2020-03-10 at 10:06 +0100, Juergen Gross wrote:
> When onlining a cpu cpupool_cpu_add() checks whether all siblings of
> the new cpu are free in order to decide whether to add it to
> cpupool0.
> In case the added cpu is not the last sibling to be onlined this test
> is wrong as it only che
On 24.03.20 16:00, Roger Pau Monne wrote:
Without it a PVH dom0 is mostly useless, as it would balloon down huge
amounts of RAM in order get physical address space to map foreign
memory and grants, ultimately leading to an out of memory situation.
Such option is also needed for HVM or PVH driver
Without it a PVH dom0 is mostly useless, as it would balloon down huge
amounts of RAM in order get physical address space to map foreign
memory and grants, ultimately leading to an out of memory situation.
Such option is also needed for HVM or PVH driver domains, since they
also require mapping gr
To mention it's also useful for PVH or HVM domains that require
mapping foreign memory or grants.
Signed-off-by: Roger Pau Monné
---
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-devel@lists.xenproject.org
---
drivers/xen/Kconfig | 4
1 file changed, 4 insertions(+
On Tue, 2020-03-24 at 15:22 +0100, Jürgen Groß wrote:
> On 24.03.20 14:34, Sergey Dyasli wrote:
> > I did some experiments and noticed
> > the following
> > inconsistencies:
> >
> >1. xl vcpu-pin 5 0 0
> > Windows 10 (64-bit) (1) 5 00
> > -b-1644.0 0 / all
>
On Tue, Mar 17, 2020 at 10:51:34AM -0700, Stefano Stabellini wrote:
> On Tue, 17 Mar 2020, Julien Grall wrote:
> > I noticed below you added "depends on ARM_64" on the Xilinx SoC. In
> > general, platform specific options are tied to either arm32 or arm64,
> > even if the UART "driver" is arch ag
> -Original Message-
[snip]
> > Currently shared_info is a shared xenheap page but shared xenheap pages
> > complicate future plans for live-update of Xen so it is desirable to,
> > where possible, not use them [1]. This patch therefore converts shared_info
> > into a PGC_extra domheap page
On 18/03/2020 17:32, Paul Durrant wrote:
This patch adds a new page_list_head into struct domain to hold PGC_extra
pages. This avoids them getting confused with 'normal' domheap pages where
the domain's page_list is walked.
A new dump loop is also added to dump_pageframe_info() to uncondition
On 18/03/2020 17:32, Paul Durrant wrote:
From: Paul Durrant
... to cover xenheap and PGC_extra pages.
PGC_extra pages are intended to hold data structures that are associated
with a domain and may be mapped by that domain. They should not be treated
as 'normal' guest pages (i.e. RAM or page
Hi Paul,
On 10/03/2020 17:49, p...@xen.org wrote:
From: Paul Durrant
Currently shared_info is a shared xenheap page but shared xenheap pages
complicate future plans for live-update of Xen so it is desirable to,
where possible, not use them [1]. This patch therefore converts shared_info
into a
On 24.03.20 14:34, Sergey Dyasli wrote:
Hi Juergen,
I've notived there is no documentation about how vcpu-pin is supposed to work
with core scheduling enabled. I did some experiments and noticed the following
inconsistencies:
1. xl vcpu-pin 5 0 0
Windows 10 (64-bit) (1) 5
Hi Juergen,
I've notived there is no documentation about how vcpu-pin is supposed to work
with core scheduling enabled. I did some experiments and noticed the following
inconsistencies:
1. xl vcpu-pin 5 0 0
Windows 10 (64-bit) (1) 5 00 -b-1644.0 0 / all
Win
On 24.03.20 13:00, Roger Pau Monné wrote:
Adding Juergen and Boris for feedback.
On Tue, Mar 24, 2020 at 11:57:48AM +, Ian Jackson wrote:
Ian Jackson writes ("Re: [PATCH OSSTEST] kernel-build: enable
XEN_BALLOON_MEMORY_HOTPLUG"):
Roger Pau Monne writes ("[PATCH OSSTEST] kernel-build: enab
Paul,On 24.03.2020 13:26, Jan Beulich wrote:
> Some of the later patches are still at least partly RFC, for
> varying reasons (see there). I'd appreciate though if at least
> some of the earlier ones could go in rather sooner than later.
>
> Patch 1 functionally (for the test harness) depends on
>
The dependency on a new EFER bit implies that we need to set that bit
ourselves in order to be able to successfully invoke the insn.
Also once again introduce the SVM related constants at this occasion.
Signed-off-by: Jan Beulich
---
RFC: The exact meaning of the PM stating "any errors encounter
If the hardware can handle accesses, we should allow it to do so. This
way we can expose EFRO to HVM guests, and "all" that's left for exposing
APERF/MPERF is to figure out how to handle writes to these MSRs. (Note
that the leaf 6 guest CPUID checks will evaluate to false for now, as
recalculate_mi
flight 148966 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148966/
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
While the PM doesn't say so, this assumes that the MPERF value read this
way gets scaled similarly to its reading through RDMSR.
Also introduce the SVM related constants at this occasion.
Signed-off-by: Jan Beulich
---
v5: The CPUID field used is just 8 bits wide.
v4: Add GENERAL2_INTERCEPT_RDPR
AMD's PM specifies that MPERF (and its r/o counterpart) reads are
affected by the TSC ratio. Hence when processing such reads in software
we too should scale the values. While we don't currently (yet) expose
the underlying feature flags, besides us allowing the MSRs to be read
nevertheless, RDPRU i
Introduce a new blk() hook, paralleling the rmw() on in certain way, but
being intended for larger data sizes, and hence its HVM intermediate
handling function doesn't fall back to splitting the operation if the
requested virtual address can't be mapped.
Note that the ISA extensions document revis
Introduce a new blk() hook, paralleling the rmw() on in certain way, but
being intended for larger data sizes, and hence its HVM intermediate
handling function doesn't fall back to splitting the operation if the
requested virtual address can't be mapped.
Note that SDM revision 071 doesn't specify
This largely reverts f19af2f1138e ("x86: re-order clang no integrated
assembler tests"): Other CFLAGS setup would better happen first, in case
any of it affects the behavior of the integrated assembler. The comment
addition of course doesn't get undone. The only remaining as-option-add
invocation g
With the exception of HAVE_AS_QUOTED_SYM, populate the results into a
generated header instead of (at least once per [sub]directory) into
CFLAGS. This results in proper rebuilds (via make dependencies) in case
the compiler used changes between builds. It additionally eases
inspection of which assem
Signed-off-by: Jan Beulich
---
v5: New.
---
(SDE: -cpx)
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -550,6 +550,12 @@ static const struct test avx512_4vnniw_5
INSN(p4dpwssds, f2, 0f38, 53, el_4, d, vl),
};
+static const struct test avx512_bf1
Note that SDM revision 070 doesn't specify exception behavior for
ModRM.mod == 0b11; assuming #UD here.
Signed-off-by: Jan Beulich
---
v4: Split MOVDIRI and MOVDIR64B and move this one ahead. Re-base.
v3: Update description.
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x8
On 24/03/2020 10:37, Pu Wen wrote:
> According to chapter "Appendix B Layout of VMCB" in the new version
> (v3.32) AMD64 APM[1], bit 1 of the VMCB offset 68h is defined as
> GUEST_INTERRUPT_MASK.
>
> In current xen codes, it use whole u64 interrupt_shadow to setup
> interrupt shadow, which will mis
Signed-off-by: Jan Beulich
---
v5: New.
---
(SDE: -cpx)
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -550,6 +550,12 @@ static const struct test avx512_4vnniw_5
INSN(p4dpwssds, f2, 0f38, 53, el_4, d, vl),
};
+static const struct test avx512_bf1
Some of the later patches are still at least partly RFC, for
varying reasons (see there). I'd appreciate though if at least
some of the earlier ones could go in rather sooner than later.
Patch 1 functionally (for the test harness) depends on
"libx86/CPUID: fix (not just) leaf 7 processing", while
On Tue, Mar 24, 2020 at 11:33:00AM +, Tian, Kevin wrote:
> > From: Roger Pau Monné
> > Sent: Tuesday, March 24, 2020 7:23 PM
> >
> > On Tue, Mar 24, 2020 at 10:11:15AM +, Tian, Kevin wrote:
> > > > From: Roger Pau Monné
> > > > Sent: Tuesday, March 24, 2020 5:51 PM
> > > >
> > > > On Tue
On 20.12.2019 14:41, Jan Beulich wrote:
> In a pure PV environment (the PV shim in particular) we don't really
> need emulation of all these. To limit #ifdef-ary utilize some of the
> CASE_*() macros we have, by providing variants expanding to
> (effectively) nothing (really a label, which in turn
Adding Juergen and Boris for feedback.
On Tue, Mar 24, 2020 at 11:57:48AM +, Ian Jackson wrote:
> Ian Jackson writes ("Re: [PATCH OSSTEST] kernel-build: enable
> XEN_BALLOON_MEMORY_HOTPLUG"):
> > Roger Pau Monne writes ("[PATCH OSSTEST] kernel-build: enable
> > XEN_BALLOON_MEMORY_HOTPLUG"):
On 24.03.2020 11:37, Pu Wen wrote:
> According to chapter "Appendix B Layout of VMCB" in the new version
> (v3.32) AMD64 APM[1], bit 1 of the VMCB offset 68h is defined as
> GUEST_INTERRUPT_MASK.
>
> In current xen codes, it use whole u64 interrupt_shadow to setup
> interrupt shadow, which will mi
Roger Pau Monne writes ("[PATCH OSSTEST] kernel-build: enable
XEN_BALLOON_MEMORY_HOTPLUG"):
> This allows a PVH/HVM domain to use unpopulated memory ranges to map
> foreign memory or grants, and is required for a PVH dom0 to function
> properly.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Ian
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-ovmf-amd64
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xe
Ping?
On 10.03.20 10:06, Juergen Gross wrote:
When onlining a cpu cpupool_cpu_add() checks whether all siblings of
the new cpu are free in order to decide whether to add it to cpupool0.
In case the added cpu is not the last sibling to be onlined this test
is wrong as it only checks for all onlin
Ping?
On 10.03.20 09:09, Juergen Gross wrote:
Offlining a cpu with core scheduling active can result in a hanging
system. Reason is the scheduling resource and unit of the to be removed
cpus needs to be split in order to remove the cpu from its cpupool and
move it to the idle scheduler. In case
> From: Roger Pau Monné
> Sent: Tuesday, March 24, 2020 7:23 PM
>
> On Tue, Mar 24, 2020 at 10:11:15AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monné
> > > Sent: Tuesday, March 24, 2020 5:51 PM
> > >
> > > On Tue, Mar 24, 2020 at 06:03:28AM +, Tian, Kevin wrote:
> > > > > From: Roger
On Tue, Mar 24, 2020 at 10:16:52AM +, Tian, Kevin wrote:
> > From: Roger Pau Monné
> > Sent: Tuesday, March 24, 2020 5:59 PM
> >
> > On Tue, Mar 24, 2020 at 06:22:43AM +, Tian, Kevin wrote:
> > > > From: Roger Pau Monne
> > > > Sent: Saturday, March 21, 2020 3:08 AM
> > > >
> > > > Curre
On Tue, Mar 24, 2020 at 10:11:15AM +, Tian, Kevin wrote:
> > From: Roger Pau Monné
> > Sent: Tuesday, March 24, 2020 5:51 PM
> >
> > On Tue, Mar 24, 2020 at 06:03:28AM +, Tian, Kevin wrote:
> > > > From: Roger Pau Monne
> > > > Sent: Saturday, March 21, 2020 3:08 AM
> > > >
> > > > The c
> From: Roger Pau Monné
> Sent: Tuesday, March 24, 2020 6:47 PM
>
> On Tue, Mar 24, 2020 at 08:49:27AM +, Tian, Kevin wrote:
> > > From: Jan Beulich
> > > Sent: Tuesday, March 24, 2020 4:10 PM
> > >
> > > On 24.03.2020 06:41, Tian, Kevin wrote:
> > > >> From: Roger Pau Monné
> > > >> Sent:
On Tue, Mar 24, 2020 at 08:49:27AM +, Tian, Kevin wrote:
> > From: Jan Beulich
> > Sent: Tuesday, March 24, 2020 4:10 PM
> >
> > On 24.03.2020 06:41, Tian, Kevin wrote:
> > >> From: Roger Pau Monné
> > >> Sent: Monday, March 23, 2020 10:49 PM
> > >>
> > >> On Mon, Mar 23, 2020 at 09:09:59AM
Hi Kevin and sorry for the long reply time,
On 10.03.2020 04:04, sTian, Kevin wrote:
From: Alexandru Stefan ISAILA
Sent: Tuesday, March 3, 2020 8:23 PM
At this moment a guest can call vmfunc to change the altp2m view. This
should be limited in order to avoid any unwanted view switch.
I lo
On 2020/3/24 17:08, Jan Beulich wrote:
> On 24.03.2020 05:52, Pu Wen wrote:
>> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
>> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
>> @@ -508,7 +508,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v,
>> struct cpu_user_regs *regs)
>> }
>>
>> /* Shad
According to chapter "Appendix B Layout of VMCB" in the new version
(v3.32) AMD64 APM[1], bit 1 of the VMCB offset 68h is defined as
GUEST_INTERRUPT_MASK.
In current xen codes, it use whole u64 interrupt_shadow to setup
interrupt shadow, which will misuse other bit in VMCB offset 68h
as part of in
> -Original Message-
> From: Jan Beulich
> Sent: 24 March 2020 09:39
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Julien
> Grall ;
> Konrad Rzeszutek Wilk ; Roger Pau Monné
> ; Stefano
> Stabellini ; Tim Deegan ; Wei Liu
>
On Mon, Mar 23, 2020 at 05:55:39PM -0400, Boris Ostrovsky wrote:
>
> On 3/23/20 12:15 PM, Yan Yankovskyi wrote:
> > Make event channel functions pass event channel port using
> > evtchn_port_t type. It eliminates signed <-> unsigned conversion.
> >
> > Signed-off-by: Yan Yankovskyi
>
>
> If the
> From: Roger Pau Monné
> Sent: Tuesday, March 24, 2020 5:59 PM
>
> On Tue, Mar 24, 2020 at 06:22:43AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monne
> > > Sent: Saturday, March 21, 2020 3:08 AM
> > >
> > > Current code in nvmx_update_apicv set the guest interrupt status field
> > > but d
Commit 562a1c0f7ef3fb ("tools/xenstore: dont unlink connection object
twice") introduced a potential use after free problem in
domain_cleanup(): after calling talloc_unlink() for domain->conn
domain->conn is set to NULL. The problem is that domain is registered
as talloc child of domain->conn, so i
> From: Roger Pau Monné
> Sent: Tuesday, March 24, 2020 5:51 PM
>
> On Tue, Mar 24, 2020 at 06:03:28AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monne
> > > Sent: Saturday, March 21, 2020 3:08 AM
> > >
> > > The current usage of nvmx_update_apicv is not clear: it is deeply
> > > intertwine
Hi David,
On 23/03/2020 10:55, David Woodhouse wrote:
On Mon, 2020-03-23 at 09:34 +, Julien Grall wrote:
For liveupdate, we will need a way to initialize a page but mark it as
already inuse (i.e in the same state as they would be if allocated
normally).
I am unconvinced of the veracity of
On Tue, Mar 24, 2020 at 06:22:43AM +, Tian, Kevin wrote:
> > From: Roger Pau Monne
> > Sent: Saturday, March 21, 2020 3:08 AM
> >
> > Current code in nvmx_update_apicv set the guest interrupt status field
> > but doesn't update the exit bitmap, which can cause issues of lost
> > interrupts on
On Tue, Mar 24, 2020 at 06:03:28AM +, Tian, Kevin wrote:
> > From: Roger Pau Monne
> > Sent: Saturday, March 21, 2020 3:08 AM
> >
> > The current usage of nvmx_update_apicv is not clear: it is deeply
> > intertwined with the Ack interrupt on exit VMEXIT control.
> >
> > The code in nvmx_upda
On 16.03.2020 14:41, Andrew Cooper wrote:
> On 16/03/2020 11:00, Jan Beulich wrote:
>> The involved comparison was, very likely inadvertently, converted from
>>> = to > when making changes unrelated to the actual family range.
>>
>> Fixes: 9841eb71ea87 ("x86/cpuid: Drop a guests cached x86 family a
On 18.03.2020 18:32, Paul Durrant wrote:
> This series was formerly called "remove one more shared xenheap page:
> shared_info" but I have dropped the patches actually changing shared_info
> and just left the PGC_extra clean-up that was previously intertwined.
>
> Paul Durrant (3):
> mm: keep PG
On 24.03.2020 10:26, Jan Beulich wrote:
> On 10.03.2020 18:49, p...@xen.org wrote:
>> From: Paul Durrant
>>
>> Currently shared_info is a shared xenheap page but shared xenheap pages
>> complicate future plans for live-update of Xen so it is desirable to,
>> where possible, not use them [1]. This
On 10.03.2020 18:49, p...@xen.org wrote:
> From: Paul Durrant
>
> Currently shared_info is a shared xenheap page but shared xenheap pages
> complicate future plans for live-update of Xen so it is desirable to,
> where possible, not use them [1]. This patch therefore converts shared_info
> into a
On 24.03.2020 05:52, Pu Wen wrote:
> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
> @@ -508,7 +508,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct
> cpu_user_regs *regs)
> }
>
> /* Shadow Mode */
> -n2vmcb->interrupt_shadow = ns_vmc
On 24.03.2020 05:51, Pu Wen wrote:
> Currently the xl dmesg output on Hygon platforms will be
> "(XEN) CPU0: AMD Fam18h machine check reporting enabled",
> which is misleading as AMD does not have family 18h (Hygon
> negotiated with AMD to confirm that only Hygon has family 18h).
>
> To correct th
> From: Jan Beulich
> Sent: Tuesday, March 24, 2020 4:10 PM
>
> On 24.03.2020 06:41, Tian, Kevin wrote:
> >> From: Roger Pau Monné
> >> Sent: Monday, March 23, 2020 10:49 PM
> >>
> >> On Mon, Mar 23, 2020 at 09:09:59AM +0100, Jan Beulich wrote:
> >>> On 20.03.2020 20:07, Roger Pau Monne wrote:
>
flight 148903 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148903/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
146121
Tests which a
On 24.03.2020 06:41, Tian, Kevin wrote:
>> From: Roger Pau Monné
>> Sent: Monday, March 23, 2020 10:49 PM
>>
>> On Mon, Mar 23, 2020 at 09:09:59AM +0100, Jan Beulich wrote:
>>> On 20.03.2020 20:07, Roger Pau Monne wrote:
This reverts commit f96e1469ad06b61796c60193daaeb9f8a96d7458.
89 matches
Mail list logo
