[PATCH v2.1] hvmloader: indicate dynamically allocated memory as ACPI NVS in e820
Guest kernel does need to know in some cases where the tables are located
to treat these regions properly. One example is kexec process where
the first kernel needs to pass firmware region locations to the second
kernel which is now a requirement after 02a3e3cdb7f12 ("x86/boot: Parse SRAT
table and count immovable memory regions").
The memory that hvmloader allocates in the reserved region mostly contains
these useful tables and could be safely indicated as ACPI without the need
to designate a sub-region specially for that. Making it non-reclaimable
(ACPI NVS) in contrast with ACPI reclaim (ACPI table) memory would avoid
potential reuse of this memory by the guest taking into account this region
may contain runtime structures like VM86 TSS, etc. If necessary, those
can be moved away later and the region marked as reclaimable.
Signed-off-by: Igor Druzhinin
---
Changes in v2.1:
- fixed previously missed uint32_t occurence
Changes in v2:
- gave more information on NVS type selection and potential alternatives
in the description
- minor type fixes suggested
---
tools/firmware/hvmloader/e820.c | 21 +
tools/firmware/hvmloader/util.c | 6 ++
tools/firmware/hvmloader/util.h | 3 +++
3 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c
index 4d1c955..0ad2f05 100644
--- a/tools/firmware/hvmloader/e820.c
+++ b/tools/firmware/hvmloader/e820.c
@@ -155,6 +155,8 @@ int build_e820_table(struct e820entry *e820,
{
unsigned int nr = 0, i, j;
uint32_t low_mem_end = hvm_info->low_mem_pgend << PAGE_SHIFT;
+unsigned long firmware_mem_end =
+RESERVED_MEMORY_DYNAMIC_START + (mem_mfns_allocated() << PAGE_SHIFT);
if ( !lowmem_reserved_base )
lowmem_reserved_base = 0xA;
@@ -199,8 +201,19 @@ int build_e820_table(struct e820entry *e820,
nr++;
/*
+ * Mark populated reserved memory that contains ACPI and other tables as
+ * ACPI NVS (non-reclaimable) space - that should help the guest to treat
+ * it correctly later (e.g. pass to the next kernel on kexec).
+ */
+
+e820[nr].addr = RESERVED_MEMBASE;
+e820[nr].size = firmware_mem_end - RESERVED_MEMBASE;
+e820[nr].type = E820_NVS;
+nr++;
+
+/*
* Explicitly reserve space for special pages.
- * This space starts at RESERVED_MEMBASE an extends to cover various
+ * This space starts after ACPI region and extends to cover various
* fixed hardware mappings (e.g., LAPIC, IOAPIC, default SVGA framebuffer).
*
* If igd_opregion_pgbase we need to split the RESERVED region in two.
@@ -210,8 +223,8 @@ int build_e820_table(struct e820entry *e820,
{
uint32_t igd_opregion_base = igd_opregion_pgbase << PAGE_SHIFT;
-e820[nr].addr = RESERVED_MEMBASE;
-e820[nr].size = (uint32_t) igd_opregion_base - RESERVED_MEMBASE;
+e820[nr].addr = firmware_mem_end;
+e820[nr].size = igd_opregion_base - firmware_mem_end;
e820[nr].type = E820_RESERVED;
nr++;
@@ -227,7 +240,7 @@ int build_e820_table(struct e820entry *e820,
}
else
{
-e820[nr].addr = RESERVED_MEMBASE;
+e820[nr].addr = firmware_mem_end;
e820[nr].size = (uint32_t)-e820[nr].addr;
e820[nr].type = E820_RESERVED;
nr++;
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 0c3f2d2..59cde4a 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -444,6 +444,12 @@ void mem_hole_populate_ram(xen_pfn_t mfn, uint32_t nr_mfns)
static uint32_t alloc_up = RESERVED_MEMORY_DYNAMIC_START - 1;
static uint32_t alloc_down = RESERVED_MEMORY_DYNAMIC_END;
+unsigned long mem_mfns_allocated(void)
+{
+return (alloc_up >> PAGE_SHIFT) -
+((RESERVED_MEMORY_DYNAMIC_START - 1) >> PAGE_SHIFT);
+}
+
xen_pfn_t mem_hole_alloc(uint32_t nr_mfns)
{
alloc_down -= nr_mfns << PAGE_SHIFT;
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 7bca641..acd673a 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -200,6 +200,9 @@ void mem_hole_populate_ram(xen_pfn_t mfn, uint32_t nr_mfns);
/* Allocate a memory hole below 4GB. */
xen_pfn_t mem_hole_alloc(uint32_t nr_mfns);
+/* Return number of pages allocated */
+unsigned long mem_mfns_allocated(void);
+
/* Allocate memory in a reserved region below 4GB. */
void *mem_alloc(uint32_t size, uint32_t align);
#define virt_to_phys(v) ((unsigned long)(v))
--
2.7.4
[PATCH v2] hvmloader: indicate dynamically allocated memory as ACPI NVS in e820
Guest kernel does need to know in some cases where the tables are located
to treat these regions properly. One example is kexec process where
the first kernel needs to pass firmware region locations to the second
kernel which is now a requirement after 02a3e3cdb7f12 ("x86/boot: Parse SRAT
table and count immovable memory regions").
The memory that hvmloader allocates in the reserved region mostly contains
these useful tables and could be safely indicated as ACPI without the need
to designate a sub-region specially for that. Making it non-reclaimable
(ACPI NVS) in contrast with regular ACPI (ACPI table) memory would avoid
potential reuse of this memory by the guest taking into account this region
may contain runtime structures like VM86 TSS, etc. If necessary, those
can be moved away later and the region marked as reclaimable.
Signed-off-by: Igor Druzhinin
---
tools/firmware/hvmloader/e820.c | 21 +
tools/firmware/hvmloader/util.c | 6 ++
tools/firmware/hvmloader/util.h | 3 +++
3 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c
index 4d1c955..0ad2f05 100644
--- a/tools/firmware/hvmloader/e820.c
+++ b/tools/firmware/hvmloader/e820.c
@@ -155,6 +155,8 @@ int build_e820_table(struct e820entry *e820,
{
unsigned int nr = 0, i, j;
uint32_t low_mem_end = hvm_info->low_mem_pgend << PAGE_SHIFT;
+unsigned long firmware_mem_end =
+RESERVED_MEMORY_DYNAMIC_START + (mem_mfns_allocated() << PAGE_SHIFT);
if ( !lowmem_reserved_base )
lowmem_reserved_base = 0xA;
@@ -199,8 +201,19 @@ int build_e820_table(struct e820entry *e820,
nr++;
/*
+ * Mark populated reserved memory that contains ACPI and other tables as
+ * ACPI NVS (non-reclaimable) space - that should help the guest to treat
+ * it correctly later (e.g. pass to the next kernel on kexec).
+ */
+
+e820[nr].addr = RESERVED_MEMBASE;
+e820[nr].size = firmware_mem_end - RESERVED_MEMBASE;
+e820[nr].type = E820_NVS;
+nr++;
+
+/*
* Explicitly reserve space for special pages.
- * This space starts at RESERVED_MEMBASE an extends to cover various
+ * This space starts after ACPI region and extends to cover various
* fixed hardware mappings (e.g., LAPIC, IOAPIC, default SVGA framebuffer).
*
* If igd_opregion_pgbase we need to split the RESERVED region in two.
@@ -210,8 +223,8 @@ int build_e820_table(struct e820entry *e820,
{
uint32_t igd_opregion_base = igd_opregion_pgbase << PAGE_SHIFT;
-e820[nr].addr = RESERVED_MEMBASE;
-e820[nr].size = (uint32_t) igd_opregion_base - RESERVED_MEMBASE;
+e820[nr].addr = firmware_mem_end;
+e820[nr].size = igd_opregion_base - firmware_mem_end;
e820[nr].type = E820_RESERVED;
nr++;
@@ -227,7 +240,7 @@ int build_e820_table(struct e820entry *e820,
}
else
{
-e820[nr].addr = RESERVED_MEMBASE;
+e820[nr].addr = firmware_mem_end;
e820[nr].size = (uint32_t)-e820[nr].addr;
e820[nr].type = E820_RESERVED;
nr++;
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 0c3f2d2..af68862 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -444,6 +444,12 @@ void mem_hole_populate_ram(xen_pfn_t mfn, uint32_t nr_mfns)
static uint32_t alloc_up = RESERVED_MEMORY_DYNAMIC_START - 1;
static uint32_t alloc_down = RESERVED_MEMORY_DYNAMIC_END;
+uint32_t mem_mfns_allocated(void)
+{
+return (alloc_up >> PAGE_SHIFT) -
+((RESERVED_MEMORY_DYNAMIC_START - 1) >> PAGE_SHIFT);
+}
+
xen_pfn_t mem_hole_alloc(uint32_t nr_mfns)
{
alloc_down -= nr_mfns << PAGE_SHIFT;
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 7bca641..98d5e02 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -200,6 +200,9 @@ void mem_hole_populate_ram(xen_pfn_t mfn, uint32_t nr_mfns);
/* Allocate a memory hole below 4GB. */
xen_pfn_t mem_hole_alloc(uint32_t nr_mfns);
+/* Return number of pages allocated */
+uint32_t mem_mfns_allocated(void);
+
/* Allocate memory in a reserved region below 4GB. */
void *mem_alloc(uint32_t size, uint32_t align);
#define virt_to_phys(v) ((unsigned long)(v))
--
2.7.4
Re: [PATCH] gitignore: Move ignores from global to subdirectories
On Tue, Sep 01, 2020 at 08:01:30AM +0200, Jan Beulich wrote: > On 01.09.2020 00:55, Elliott Mitchell wrote: > > On Mon, Aug 31, 2020 at 08:52:45AM +0200, Jan Beulich wrote: > >> On 31.08.2020 08:37, Elliott Mitchell wrote: > >>> Preferences in sorting? > >> > >> Alphabetical sorting is what we generally aim for here. > > > > Going into specific example since those best demonstrate what I > > observed. > > > > Before this patch the top-level .gitignore included the lines: > > @@ > > -tools/misc/cpuperf/cpuperf-perfcntr > > -tools/misc/cpuperf/cpuperf-xen > > -tools/misc/xc_shadow > > -tools/misc/xen_cpuperf > > -tools/misc/xen-cpuid > > @@ > > -xen/xsm/flask/policy.* > > -xen/xsm/flask/xenpolicy-* > > tools/flask/policy/policy.conf > > tools/flask/policy/xenpolicy-* > > xen/xen > > @@ > > > > tools/misc/.gitignore had the single line: > > xen-ucode > > > > xen/xsm/flask/.gitignore had the single line: > > /policy.c > > > > > > You'll note from the second batch, .gitignore isn't consistently sorted. > > I'm aware, and hence I said "aim for". In cases like this what we > often do is adjust things incrementally, as lines get touched anyway. > Of course if you want to clean it up all in one go ... I may, though right now I'm having the experience of reading documentation several times to double-check and discovering I misinterpreted when testing. There is also the difficulty of trying to figure out why some things were done the way they were. Really starts to look like everyone (including myself) tries to intuit how .gitignore files work and doesn't /quite/ get it right 9 times out of 10. *Definitely* going to need that v2... -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
[ovmf test] 153442: regressions - FAIL
flight 153442 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153442/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm 6 xen-buildfail REGR. vs. 152863
build-amd64 6 xen-buildfail REGR. vs. 152863
build-i3866 xen-buildfail REGR. vs. 152863
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 1 build-check(1) blocked n/a
build-i386-libvirt1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
version targeted for testing:
ovmf 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
baseline version:
ovmf 63d92674d240ab4ecab94f98e1e198842bb7de00
Last test of basis 152863 2020-08-26 16:09:47 Z5 days
Failing since152915 2020-08-27 18:09:42 Z4 days 92 attempts
Testing same since 153135 2020-08-30 02:28:59 Z2 days 36 attempts
People who touched revisions under test:
Laszlo Ersek
Paul
Paul G
jobs:
build-amd64-xsm fail
build-i386-xsm fail
build-amd64 fail
build-i386 fail
build-amd64-libvirt blocked
build-i386-libvirt blocked
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
test-amd64-i386-xl-qemuu-ovmf-amd64 blocked
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 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
Author: Paul
Date: Fri Aug 28 04:40:51 2020 +0800
MdePkg: Correcting EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT definition
In Acpi10.h, EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT is defined as 0x10,
but should be 0x02 per the ACPI Specification.
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2937
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Signed-off-by: Paul G
Reviewed-by: Liming Gao
commit cbccf995920a28071f5403b847f29ebf8b732fa9
Author: Laszlo Ersek
Date: Thu Aug 27 00:21:29 2020 +0200
OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just after SMI broadcast
The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick
succession -- it means a series of "device_add" QEMU monitor commands,
back-to-back.
If a "device_add" occurs *just after* ACPI raises the broadcast SMI, then:
- the CPU_FOREACH() loop in QEMU's ich9_apm_ctrl_changed() cannot make the
SMI pending for the new CPU -- at that time, the new CPU doesn't even
exist yet,
- OVMF will find the new CPU however (in the CPU hotplug register block),
in QemuCpuhpCollectApicIds().
As a result, when the firmware sends an INIT-SIPI-SIPI to the new CPU in
SmbaseRelocate(), expecting it to boot into SMM (due to the pending SMI),
the new CPU instead boots straight into the post-RSM (normal mode) "pen",
skipping its initial SMI handler.
The CPU halts nicely in the pen, but its SMBASE is never relocated, and
the SMRAM message exchange with the BSP falls apart -- the BSP gets stuck
in the following loop:
//
// Wait until the hot-added CPU is just about to execute RSM.
//
while (Context->AboutToLeaveSmm == 0) {
CpuPause ();
}
because the new CPU's initial SMI handler never sets the flag to nonzero.
Fix this by sending a directed SMI to the new CPU just before sending it
the INIT-SIPI-SIPI. The various scenarios are documented in the code --
the cases affected by the patch are documented under point (2).
Note that this is not considered a security patch, as for
Re: [PATCH] gitignore: Move ignores from global to subdirectories
On 01.09.2020 00:55, Elliott Mitchell wrote: > On Mon, Aug 31, 2020 at 08:52:45AM +0200, Jan Beulich wrote: >> On 31.08.2020 08:37, Elliott Mitchell wrote: >>> Preferences in sorting? >> >> Alphabetical sorting is what we generally aim for here. > > Going into specific example since those best demonstrate what I > observed. > > Before this patch the top-level .gitignore included the lines: > @@ > -tools/misc/cpuperf/cpuperf-perfcntr > -tools/misc/cpuperf/cpuperf-xen > -tools/misc/xc_shadow > -tools/misc/xen_cpuperf > -tools/misc/xen-cpuid > @@ > -xen/xsm/flask/policy.* > -xen/xsm/flask/xenpolicy-* > tools/flask/policy/policy.conf > tools/flask/policy/xenpolicy-* > xen/xen > @@ > > tools/misc/.gitignore had the single line: > xen-ucode > > xen/xsm/flask/.gitignore had the single line: > /policy.c > > > You'll note from the second batch, .gitignore isn't consistently sorted. I'm aware, and hence I said "aim for". In cases like this what we often do is adjust things incrementally, as lines get touched anyway. Of course if you want to clean it up all in one go ... Jan
[ovmf test] 153436: regressions - FAIL
flight 153436 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153436/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm 6 xen-buildfail REGR. vs. 152863
build-amd64 6 xen-buildfail REGR. vs. 152863
build-i3866 xen-buildfail REGR. vs. 152863
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 1 build-check(1) blocked n/a
build-i386-libvirt1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
version targeted for testing:
ovmf 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
baseline version:
ovmf 63d92674d240ab4ecab94f98e1e198842bb7de00
Last test of basis 152863 2020-08-26 16:09:47 Z5 days
Failing since152915 2020-08-27 18:09:42 Z4 days 91 attempts
Testing same since 153135 2020-08-30 02:28:59 Z2 days 35 attempts
People who touched revisions under test:
Laszlo Ersek
Paul
Paul G
jobs:
build-amd64-xsm fail
build-i386-xsm fail
build-amd64 fail
build-i386 fail
build-amd64-libvirt blocked
build-i386-libvirt blocked
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
test-amd64-i386-xl-qemuu-ovmf-amd64 blocked
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 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
Author: Paul
Date: Fri Aug 28 04:40:51 2020 +0800
MdePkg: Correcting EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT definition
In Acpi10.h, EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT is defined as 0x10,
but should be 0x02 per the ACPI Specification.
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2937
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Signed-off-by: Paul G
Reviewed-by: Liming Gao
commit cbccf995920a28071f5403b847f29ebf8b732fa9
Author: Laszlo Ersek
Date: Thu Aug 27 00:21:29 2020 +0200
OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just after SMI broadcast
The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick
succession -- it means a series of "device_add" QEMU monitor commands,
back-to-back.
If a "device_add" occurs *just after* ACPI raises the broadcast SMI, then:
- the CPU_FOREACH() loop in QEMU's ich9_apm_ctrl_changed() cannot make the
SMI pending for the new CPU -- at that time, the new CPU doesn't even
exist yet,
- OVMF will find the new CPU however (in the CPU hotplug register block),
in QemuCpuhpCollectApicIds().
As a result, when the firmware sends an INIT-SIPI-SIPI to the new CPU in
SmbaseRelocate(), expecting it to boot into SMM (due to the pending SMI),
the new CPU instead boots straight into the post-RSM (normal mode) "pen",
skipping its initial SMI handler.
The CPU halts nicely in the pen, but its SMBASE is never relocated, and
the SMRAM message exchange with the BSP falls apart -- the BSP gets stuck
in the following loop:
//
// Wait until the hot-added CPU is just about to execute RSM.
//
while (Context->AboutToLeaveSmm == 0) {
CpuPause ();
}
because the new CPU's initial SMI handler never sets the flag to nonzero.
Fix this by sending a directed SMI to the new CPU just before sending it
the INIT-SIPI-SIPI. The various scenarios are documented in the code --
the cases affected by the patch are documented under point (2).
Note that this is not considered a security patch, as for
[linux-linus test] 153416: regressions - FAIL
flight 153416 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/153416/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3866 xen-buildfail REGR. vs. 152332 build-amd64-xsm 6 xen-buildfail REGR. vs. 152332 build-amd64 6 xen-buildfail REGR. vs. 152332 build-i386-xsm6 xen-buildfail REGR. vs. 152332 Tests which did not succeed, but are not blocking: test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-examine 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd11-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd12-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64
[xen-unstable test] 153400: regressions - FAIL
flight 153400 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/153400/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 152877 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 152877 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 152877 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 152877 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 152877 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 152877 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 152877 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 152877 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 152877 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 152877 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 152877 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass version targeted for testing: xen afe018e041ec112d90a8b4e6ed607d22aa06f280 baseline version: xen 7a8d8bde9820387c3e168182b99fd9761c223fff Last test of basis 152877 2020-08-27 01:51:40 Z5 days Failing since152896 2020-08-27 13:07:51 Z4 days 14 attempts Testing same since 153400 2020-08-31 18:07:29 Z0 days1 attempts -
[qemu-mainline test] 153406: regressions - FAIL
flight 153406 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/153406/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3866 xen-buildfail REGR. vs. 152631 build-amd64-xsm 6 xen-buildfail REGR. vs. 152631 build-i386-xsm6 xen-buildfail REGR. vs. 152631 build-amd64 6 xen-buildfail REGR. vs. 152631 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 152631 test-armhf-armhf-xl-vhd 10 debian-di-installfail REGR. vs. 152631 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 152631 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 152631 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 152631 Tests which did not succeed, but are not blocking: test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd11-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd12-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qem
[ovmf test] 153431: regressions - FAIL
flight 153431 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153431/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm 6 xen-buildfail REGR. vs. 152863
build-amd64 6 xen-buildfail REGR. vs. 152863
build-i3866 xen-buildfail REGR. vs. 152863
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 1 build-check(1) blocked n/a
build-i386-libvirt1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
version targeted for testing:
ovmf 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
baseline version:
ovmf 63d92674d240ab4ecab94f98e1e198842bb7de00
Last test of basis 152863 2020-08-26 16:09:47 Z5 days
Failing since152915 2020-08-27 18:09:42 Z4 days 90 attempts
Testing same since 153135 2020-08-30 02:28:59 Z2 days 34 attempts
People who touched revisions under test:
Laszlo Ersek
Paul
Paul G
jobs:
build-amd64-xsm fail
build-i386-xsm fail
build-amd64 fail
build-i386 fail
build-amd64-libvirt blocked
build-i386-libvirt blocked
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
test-amd64-i386-xl-qemuu-ovmf-amd64 blocked
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 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
Author: Paul
Date: Fri Aug 28 04:40:51 2020 +0800
MdePkg: Correcting EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT definition
In Acpi10.h, EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT is defined as 0x10,
but should be 0x02 per the ACPI Specification.
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2937
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Signed-off-by: Paul G
Reviewed-by: Liming Gao
commit cbccf995920a28071f5403b847f29ebf8b732fa9
Author: Laszlo Ersek
Date: Thu Aug 27 00:21:29 2020 +0200
OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just after SMI broadcast
The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick
succession -- it means a series of "device_add" QEMU monitor commands,
back-to-back.
If a "device_add" occurs *just after* ACPI raises the broadcast SMI, then:
- the CPU_FOREACH() loop in QEMU's ich9_apm_ctrl_changed() cannot make the
SMI pending for the new CPU -- at that time, the new CPU doesn't even
exist yet,
- OVMF will find the new CPU however (in the CPU hotplug register block),
in QemuCpuhpCollectApicIds().
As a result, when the firmware sends an INIT-SIPI-SIPI to the new CPU in
SmbaseRelocate(), expecting it to boot into SMM (due to the pending SMI),
the new CPU instead boots straight into the post-RSM (normal mode) "pen",
skipping its initial SMI handler.
The CPU halts nicely in the pen, but its SMBASE is never relocated, and
the SMRAM message exchange with the BSP falls apart -- the BSP gets stuck
in the following loop:
//
// Wait until the hot-added CPU is just about to execute RSM.
//
while (Context->AboutToLeaveSmm == 0) {
CpuPause ();
}
because the new CPU's initial SMI handler never sets the flag to nonzero.
Fix this by sending a directed SMI to the new CPU just before sending it
the INIT-SIPI-SIPI. The various scenarios are documented in the code --
the cases affected by the patch are documented under point (2).
Note that this is not considered a security patch, as for
[ovmf test] 153428: regressions - FAIL
flight 153428 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153428/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm 6 xen-buildfail REGR. vs. 152863
build-amd64 6 xen-buildfail REGR. vs. 152863
build-i3866 xen-buildfail REGR. vs. 152863
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 1 build-check(1) blocked n/a
build-i386-libvirt1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
version targeted for testing:
ovmf 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
baseline version:
ovmf 63d92674d240ab4ecab94f98e1e198842bb7de00
Last test of basis 152863 2020-08-26 16:09:47 Z5 days
Failing since152915 2020-08-27 18:09:42 Z4 days 89 attempts
Testing same since 153135 2020-08-30 02:28:59 Z2 days 33 attempts
People who touched revisions under test:
Laszlo Ersek
Paul
Paul G
jobs:
build-amd64-xsm fail
build-i386-xsm fail
build-amd64 fail
build-i386 fail
build-amd64-libvirt blocked
build-i386-libvirt blocked
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
test-amd64-i386-xl-qemuu-ovmf-amd64 blocked
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 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
Author: Paul
Date: Fri Aug 28 04:40:51 2020 +0800
MdePkg: Correcting EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT definition
In Acpi10.h, EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT is defined as 0x10,
but should be 0x02 per the ACPI Specification.
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2937
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Signed-off-by: Paul G
Reviewed-by: Liming Gao
commit cbccf995920a28071f5403b847f29ebf8b732fa9
Author: Laszlo Ersek
Date: Thu Aug 27 00:21:29 2020 +0200
OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just after SMI broadcast
The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick
succession -- it means a series of "device_add" QEMU monitor commands,
back-to-back.
If a "device_add" occurs *just after* ACPI raises the broadcast SMI, then:
- the CPU_FOREACH() loop in QEMU's ich9_apm_ctrl_changed() cannot make the
SMI pending for the new CPU -- at that time, the new CPU doesn't even
exist yet,
- OVMF will find the new CPU however (in the CPU hotplug register block),
in QemuCpuhpCollectApicIds().
As a result, when the firmware sends an INIT-SIPI-SIPI to the new CPU in
SmbaseRelocate(), expecting it to boot into SMM (due to the pending SMI),
the new CPU instead boots straight into the post-RSM (normal mode) "pen",
skipping its initial SMI handler.
The CPU halts nicely in the pen, but its SMBASE is never relocated, and
the SMRAM message exchange with the BSP falls apart -- the BSP gets stuck
in the following loop:
//
// Wait until the hot-added CPU is just about to execute RSM.
//
while (Context->AboutToLeaveSmm == 0) {
CpuPause ();
}
because the new CPU's initial SMI handler never sets the flag to nonzero.
Fix this by sending a directed SMI to the new CPU just before sending it
the INIT-SIPI-SIPI. The various scenarios are documented in the code --
the cases affected by the patch are documented under point (2).
Note that this is not considered a security patch, as for
[ovmf test] 153417: regressions - FAIL
flight 153417 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153417/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm 6 xen-buildfail REGR. vs. 152863
build-amd64 6 xen-buildfail REGR. vs. 152863
build-i3866 xen-buildfail REGR. vs. 152863
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 1 build-check(1) blocked n/a
build-i386-libvirt1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
version targeted for testing:
ovmf 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
baseline version:
ovmf 63d92674d240ab4ecab94f98e1e198842bb7de00
Last test of basis 152863 2020-08-26 16:09:47 Z5 days
Failing since152915 2020-08-27 18:09:42 Z4 days 88 attempts
Testing same since 153135 2020-08-30 02:28:59 Z1 days 32 attempts
People who touched revisions under test:
Laszlo Ersek
Paul
Paul G
jobs:
build-amd64-xsm fail
build-i386-xsm fail
build-amd64 fail
build-i386 fail
build-amd64-libvirt blocked
build-i386-libvirt blocked
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
test-amd64-i386-xl-qemuu-ovmf-amd64 blocked
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 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
Author: Paul
Date: Fri Aug 28 04:40:51 2020 +0800
MdePkg: Correcting EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT definition
In Acpi10.h, EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT is defined as 0x10,
but should be 0x02 per the ACPI Specification.
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2937
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Signed-off-by: Paul G
Reviewed-by: Liming Gao
commit cbccf995920a28071f5403b847f29ebf8b732fa9
Author: Laszlo Ersek
Date: Thu Aug 27 00:21:29 2020 +0200
OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just after SMI broadcast
The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick
succession -- it means a series of "device_add" QEMU monitor commands,
back-to-back.
If a "device_add" occurs *just after* ACPI raises the broadcast SMI, then:
- the CPU_FOREACH() loop in QEMU's ich9_apm_ctrl_changed() cannot make the
SMI pending for the new CPU -- at that time, the new CPU doesn't even
exist yet,
- OVMF will find the new CPU however (in the CPU hotplug register block),
in QemuCpuhpCollectApicIds().
As a result, when the firmware sends an INIT-SIPI-SIPI to the new CPU in
SmbaseRelocate(), expecting it to boot into SMM (due to the pending SMI),
the new CPU instead boots straight into the post-RSM (normal mode) "pen",
skipping its initial SMI handler.
The CPU halts nicely in the pen, but its SMBASE is never relocated, and
the SMRAM message exchange with the BSP falls apart -- the BSP gets stuck
in the following loop:
//
// Wait until the hot-added CPU is just about to execute RSM.
//
while (Context->AboutToLeaveSmm == 0) {
CpuPause ();
}
because the new CPU's initial SMI handler never sets the flag to nonzero.
Fix this by sending a directed SMI to the new CPU just before sending it
the INIT-SIPI-SIPI. The various scenarios are documented in the code --
the cases affected by the patch are documented under point (2).
Note that this is not considered a security patch, as for
[PATCH 2/2] golang/xenlight: use struct pointers in keyed union fields
Currently, when marshalig Go types with keyed union fields, we assign the
value of the struct (e.g. DomainBuildInfoTypeUnionHvm) which implements the
interface of the keyed union field (e.g. DomainBuildInfoTypeUnion).
As-is, this means that if a populated DomainBuildInfo is marshaled to
e.g. JSON, unmarshaling back to DomainBuildInfo will fail.
When the encoding/json is unmarshaling data into a Go type, and
encounters a JSON object, it basically can either marshal the data into
an empty interface, a map, or a struct. It cannot, however, marshal data
into an interface with at least one method defined on it (e.g.
DomainBuildInfoTypeUnion). Before this check is done, however, the
decoder will check if the Go type is a pointer, and dereference it if
so. It will then use the type of this value as the "target" type.
This means that if the TypeUnion field is populated with a
DomainBuildInfoTypeUnion, the decoder will see a non-empty interface and
fail. If the TypeUnion field is populated with a
*DomainBuildInfoTypeUnionHvm, it dereferences the pointer and sees a
struct instead, allowing decoding to continue normally.
Since there does not appear to be a strict need for NOT using pointers
in these fields, update code generation to set keyed union fields to
pointers of their implementing structs.
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/gengotypes.py | 4 +--
tools/golang/xenlight/helpers.gen.go | 44 ++--
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/tools/golang/xenlight/gengotypes.py
b/tools/golang/xenlight/gengotypes.py
index 9acc8c0b49..a802c371b6 100644
--- a/tools/golang/xenlight/gengotypes.py
+++ b/tools/golang/xenlight/gengotypes.py
@@ -397,7 +397,7 @@ def xenlight_golang_union_from_C(ty = None, union_name =
'', struct_name = ''):
s += 'if err := {0}.fromC(xc);'.format(goname)
s += 'err != nil {{\n return fmt.Errorf("converting field {0}: %v",
err)\n}}\n'.format(goname)
-s += 'x.{0} = {1}\n'.format(field_name, goname)
+s += 'x.{0} = &{1}\n'.format(field_name, goname)
# End switch statement
s += 'default:\n'
@@ -563,7 +563,7 @@ def xenlight_golang_union_to_C(ty = None, union_name = '',
gotype = xenlight_golang_fmt_name(cgotype)
field_name = xenlight_golang_fmt_name('{0}_union'.format(keyname))
-s += 'tmp, ok := x.{0}.({1})\n'.format(field_name,gotype)
+s += 'tmp, ok := x.{0}.(*{1})\n'.format(field_name,gotype)
s += 'if !ok {\n'
s += 'return errors.New("wrong type for union key
{0}")\n'.format(keyname)
s += '}\n'
diff --git a/tools/golang/xenlight/helpers.gen.go
b/tools/golang/xenlight/helpers.gen.go
index 152c7e8e6b..1a7ff89c7c 100644
--- a/tools/golang/xenlight/helpers.gen.go
+++ b/tools/golang/xenlight/helpers.gen.go
@@ -436,7 +436,7 @@ var connectionPty ChannelinfoConnectionUnionPty
if err := connectionPty.fromC(xc);err != nil {
return fmt.Errorf("converting field connectionPty: %v", err)
}
-x.ConnectionUnion = connectionPty
+x.ConnectionUnion = &connectionPty
case ChannelConnectionSocket:
x.ConnectionUnion = nil
case ChannelConnectionUnknown:
@@ -476,7 +476,7 @@ switch x.Connection{
case ChannelConnectionUnknown:
break
case ChannelConnectionPty:
-tmp, ok := x.ConnectionUnion.(ChannelinfoConnectionUnionPty)
+tmp, ok := x.ConnectionUnion.(*ChannelinfoConnectionUnionPty)
if !ok {
return errors.New("wrong type for union key connection")
}
@@ -1097,7 +1097,7 @@ var typeHvm DomainBuildInfoTypeUnionHvm
if err := typeHvm.fromC(xc);err != nil {
return fmt.Errorf("converting field typeHvm: %v", err)
}
-x.TypeUnion = typeHvm
+x.TypeUnion = &typeHvm
case DomainTypeInvalid:
x.TypeUnion = nil
case DomainTypePv:
@@ -1105,13 +1105,13 @@ var typePv DomainBuildInfoTypeUnionPv
if err := typePv.fromC(xc);err != nil {
return fmt.Errorf("converting field typePv: %v", err)
}
-x.TypeUnion = typePv
+x.TypeUnion = &typePv
case DomainTypePvh:
var typePvh DomainBuildInfoTypeUnionPvh
if err := typePvh.fromC(xc);err != nil {
return fmt.Errorf("converting field typePvh: %v", err)
}
-x.TypeUnion = typePvh
+x.TypeUnion = &typePvh
default:
return fmt.Errorf("invalid union key '%v'", x.Type)}
x.ArchArm.GicVersion = GicVersion(xc.arch_arm.gic_version)
@@ -1426,7 +1426,7 @@ xc.tee = C.libxl_tee_type(x.Tee)
xc._type = C.libxl_domain_type(x.Type)
switch x.Type{
case DomainTypeHvm:
-tmp, ok := x.TypeUnion.(DomainBuildInfoTypeUnionHvm)
+tmp, ok := x.TypeUnion.(*DomainBuildInfoTypeUnionHvm)
if !ok {
return errors.New("wrong type for union key type")
}
@@ -1544,7 +1544,7 @@ hvm.mca_caps = C.uint64_t(tmp.McaCaps)
hvmBytes :=
C.GoBytes(unsafe.Pointer(&hvm),C.sizeof_libxl_domain_build_info_type_union_hvm)
copy(xc.u[:],hvmBytes)
case DomainTypePv:
-tmp, ok := x.TypeUnion.(DomainBuildInfoTypeUnionPv)
+tmp, ok := x.TypeUnion.(*DomainBuildInfoTypeUnionPv)
if !ok {
return errors.New("wrong type for union key type")
}
@@ -1569,7 +1
[PATCH 0/2] make keyed union types easier to marshal
These patches make changes to the generated "keyed union" types that allow marshaling and unmarshaling easier, specifically when using the encoding/json package from the Go standard library. Nick Rosbrook (2): golang/xenlight: export keyed union interface types golang/xenlight: use struct pointers in keyed union fields tools/golang/xenlight/gengotypes.py | 10 ++--- tools/golang/xenlight/helpers.gen.go | 44 ++--- tools/golang/xenlight/types.gen.go | 58 ++-- 3 files changed, 56 insertions(+), 56 deletions(-) -- 2.17.1
[PATCH 1/2] golang/xenlight: export keyed union interface types
For structs that have a keyed union, e.g. DomainBuildInfo, the TypeUnion
field must be exported so that package users can get/set the fields
within. This means that users are aware of the existence of the
interface type used in those fields (see [1]), so it is awkward that the
interface itself is not exported. However, the single method within the
interface must remain unexported so that users cannot mistakenly "implement"
those interfaces.
Since there seems to be no reason to do otherwise, export the keyed
union interface types.
[1]
https://pkg.go.dev/xenbits.xenproject.org/git-http/xen.git/tools/golang/xenlight?tab=doc#DeviceUsbdev
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/gengotypes.py | 6 +--
tools/golang/xenlight/types.gen.go | 58 ++---
2 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/tools/golang/xenlight/gengotypes.py
b/tools/golang/xenlight/gengotypes.py
index ebec938224..9acc8c0b49 100644
--- a/tools/golang/xenlight/gengotypes.py
+++ b/tools/golang/xenlight/gengotypes.py
@@ -152,7 +152,7 @@ def xenlight_golang_define_union(ty = None, struct_name =
'', union_name = ''):
extras = []
interface_name = '{0}_{1}_union'.format(struct_name, ty.keyvar.name)
-interface_name = xenlight_golang_fmt_name(interface_name, exported=False)
+interface_name = xenlight_golang_fmt_name(interface_name)
s += 'type {0} interface {{\n'.format(interface_name)
s += 'is{0}()\n'.format(interface_name)
@@ -334,7 +334,7 @@ def xenlight_golang_union_from_C(ty = None, union_name =
'', struct_name = ''):
field_name = xenlight_golang_fmt_name('{0}_union'.format(keyname))
interface_name = '{0}_{1}_union'.format(struct_name, keyname)
-interface_name = xenlight_golang_fmt_name(interface_name, exported=False)
+interface_name = xenlight_golang_fmt_name(interface_name)
cgo_keyname = keyname
if cgo_keyname in go_keywords:
@@ -538,7 +538,7 @@ def xenlight_golang_union_to_C(ty = None, union_name = '',
gokeytype = xenlight_golang_fmt_name(keytype)
interface_name = '{0}_{1}_union'.format(struct_name, keyname)
-interface_name = xenlight_golang_fmt_name(interface_name, exported=False)
+interface_name = xenlight_golang_fmt_name(interface_name)
cgo_keyname = keyname
if cgo_keyname in go_keywords:
diff --git a/tools/golang/xenlight/types.gen.go
b/tools/golang/xenlight/types.gen.go
index 663c1e86b4..b143e32a9c 100644
--- a/tools/golang/xenlight/types.gen.go
+++ b/tools/golang/xenlight/types.gen.go
@@ -337,18 +337,18 @@ State int
Evtch int
Rref int
Connection ChannelConnection
-ConnectionUnion channelinfoConnectionUnion
+ConnectionUnion ChannelinfoConnectionUnion
}
-type channelinfoConnectionUnion interface {
-ischannelinfoConnectionUnion()
+type ChannelinfoConnectionUnion interface {
+isChannelinfoConnectionUnion()
}
type ChannelinfoConnectionUnionPty struct {
Path string
}
-func (x ChannelinfoConnectionUnionPty) ischannelinfoConnectionUnion(){}
+func (x ChannelinfoConnectionUnionPty) isChannelinfoConnectionUnion(){}
type Vminfo struct {
Uuid Uuid
@@ -510,7 +510,7 @@ Apic Defbool
DmRestrict Defbool
Tee TeeType
Type DomainType
-TypeUnion domainBuildInfoTypeUnion
+TypeUnion DomainBuildInfoTypeUnion
ArchArm struct {
GicVersion GicVersion
Vuart VuartType
@@ -518,8 +518,8 @@ Vuart VuartType
Altp2M Altp2MMode
}
-type domainBuildInfoTypeUnion interface {
-isdomainBuildInfoTypeUnion()
+type DomainBuildInfoTypeUnion interface {
+isDomainBuildInfoTypeUnion()
}
type DomainBuildInfoTypeUnionHvm struct {
@@ -571,7 +571,7 @@ RdmMemBoundaryMemkb uint64
McaCaps uint64
}
-func (x DomainBuildInfoTypeUnionHvm) isdomainBuildInfoTypeUnion(){}
+func (x DomainBuildInfoTypeUnionHvm) isDomainBuildInfoTypeUnion(){}
type DomainBuildInfoTypeUnionPv struct {
Kernel string
@@ -584,7 +584,7 @@ Features string
E820Host Defbool
}
-func (x DomainBuildInfoTypeUnionPv) isdomainBuildInfoTypeUnion(){}
+func (x DomainBuildInfoTypeUnionPv) isDomainBuildInfoTypeUnion(){}
type DomainBuildInfoTypeUnionPvh struct {
Pvshim Defbool
@@ -593,7 +593,7 @@ PvshimCmdline string
PvshimExtra string
}
-func (x DomainBuildInfoTypeUnionPvh) isdomainBuildInfoTypeUnion(){}
+func (x DomainBuildInfoTypeUnionPvh) isDomainBuildInfoTypeUnion(){}
type DeviceVfb struct {
BackendDomid Domid
@@ -756,11 +756,11 @@ type DeviceUsbdev struct {
Ctrl Devid
Port int
Type UsbdevType
-TypeUnion deviceUsbdevTypeUnion
+TypeUnion DeviceUsbdevTypeUnion
}
-type deviceUsbdevTypeUnion interface {
-isdeviceUsbdevTypeUnion()
+type DeviceUsbdevTypeUnion interface {
+isDeviceUsbdevTypeUnion()
}
type DeviceUsbdevTypeUnionHostdev struct {
@@ -768,7 +768,7 @@ Hostbus byte
Hostaddr byte
}
-func (x DeviceUsbdevTypeUnionHostdev) isdeviceUsbdevTypeUnion(){}
+func (x DeviceUsbdevTypeUnionHostdev) isDeviceUsbdevTypeUnion(){}
type DeviceDtdev struct {
Path string
@@ -802,18 +802,18 @@ BackendDomname string
Devid
Re: [PATCH] gitignore: Move ignores from global to subdirectories
On Mon, Aug 31, 2020 at 10:04:54AM +, George Dunlap wrote: > > Storing the extra paragraph in git is cheap; trying to reconstruct why > someone made a change 10 years after the fact is often difficult. Probably > not worth a re-send ??? it can be moved into the commit message by the > committer; but if you???re going to send v2 anyway, might as well move it in. > I'm pretty sure there will be at this point. Just an issue of how many more adjustments there will be. On Mon, Aug 31, 2020 at 08:52:45AM +0200, Jan Beulich wrote: > On 31.08.2020 08:37, Elliott Mitchell wrote: > > On Fri, Aug 28, 2020 at 09:24:41AM +0200, Jan Beulich wrote: > >> On 28.08.2020 04:57, Elliott Mitchell wrote: > >>> Subdirectories which have .gitignore files should not be referenced in > >>> the global .gitignore files. Move several lines to appropriate subdirs. > >>> > >>> Signed-off-by: Elliott Mitchell > >>> > >>> --- > >>> Hopefully the commit message covers it. When moved to the subdirectories > >>> I'm using "./" as otherwise any file sharing the name in a deeper > >>> subdirectory would be subject to the match. > >> > >> May I ask why this last sentence isn't part of the commit message? > > > > My thinking is it was pretty straightforward to figure out when looking. > > Not /quite/ obvious enough to avoid commenting in e-mail, but not quite > > obscure enough to have in commit message. This can go either way really. > > Your statements below really look to me as if this wasn't this obvious > at all - ... Things were sufficiently obvious when it was important. This though is not an issue worthy of more discussion since I've got no real objection to including the extra sentence. I suspect there will be more changes though... > > The .gitignore files aren't very consistent. I'm unsure whether it is > > worth going after the inconsistencies, but it is certainly there. > > > > Before this I noticed xen/xsm/flask/.gitignore had "/policy.c", which > > overlapped with "xen/xsm/flask/policy.*" in the top-level .gitignore. > > Checking the documentation on .gitignore files if it simply had > > "policy.c", git would have ignored any file name "policy.c" in > > subdirectories. > > > > Is it better to prefix lines in the current directory with "./" versus > > "/"? (I kind of like "./" since it looks like a relative path, but it > > *isn't* actually a relative path) > > ... you even look to suggest here that there are two alternative > forms which both have the same meaning. Personally I agree that > ./ may be more "natural" to use than /, but the question then is > what the conventions are. I can't answer this. > > > Should files in subdirectories also include "./"? > > If "no prefix at all" includes, as you say, also files in subdirs, > then the answer probably is "depends". > > > Preferences in sorting? > > Alphabetical sorting is what we generally aim for here. Going into specific example since those best demonstrate what I observed. Before this patch the top-level .gitignore included the lines: @@ -tools/misc/cpuperf/cpuperf-perfcntr -tools/misc/cpuperf/cpuperf-xen -tools/misc/xc_shadow -tools/misc/xen_cpuperf -tools/misc/xen-cpuid @@ -xen/xsm/flask/policy.* -xen/xsm/flask/xenpolicy-* tools/flask/policy/policy.conf tools/flask/policy/xenpolicy-* xen/xen @@ tools/misc/.gitignore had the single line: xen-ucode xen/xsm/flask/.gitignore had the single line: /policy.c You'll note from the second batch, .gitignore isn't consistently sorted. xen/xsm/flask/.gitignore was actually good since it caused me to look at the documentation for gitignore. The effect is xen/xsm/flask/policy.c is ignored, but xen/xsm/flask/policy/policy.c and xen/xsm/flask/ss/policy.c will *not* be ignored. tools/misc/.gitignore's format means if in the future subdirectories "a" or "b" got created, tools/misc/a/xen-ucode and tools/misc/b/xen-ucode *would* be ignored in addition to tools/misc/xen-ucode. When looking at the situation I decided this was /likely/ wrong, and so changed to "./xen-ucode". So there are a few variants of how tools/misc/.gitignore could look after a patch. Two sets of lines demonstrating the possibilities: Example 0: ./cpuperf/cpuperf-perfcntr ./cpuperf/cpuperf-xen ./lowmemd ./xc_shadow Example 1: cpuperf/cpuperf-perfcntr cpuperf/cpuperf-xen /lowmemd /xc_shadow So which prefix is better for files in the current directory, "./" or "/"? "./" looks more like a reference to the current directory, "/" is shorter and the single pre-existing example used the latter. Should the paths "cpuperf/cpuperf-perfcntr" and "cpuperf/cpuperf-xen" include that prefix? I'm inclined towards having it everywhere for greater consistency, but I'm not fully set in this strategy. In other news, I think the tools/ and xen/ directories need their own .gitignore files. They are the largest portion of targeted filenames and thus seem likely candidates for breaking off. docs/ and stubdom/ are also candidates for similar
Code of Conduct vote outcome
Hey all, This is a resolution to the Code of Conduct vote Lars called for back in January [1], which ended 31 March. The results were: Hypervisior project (7 + 1 LT members): Six +1 votes, no -1 votes XAPI project (5 LT members): No votes Windows PV Drivers Project (3 LT members): One +1 vote, no -1 votes Now to interpret the governance rules on project-wide decisions [2]. It states that: "A quorum of at least least 1/3 of positive votes of each project’s leadership team members is required. In other words: if a project’s leadership team does not achieve the quorum, the entire sub-project’s vote is not counted.” That would mean that the HV project and the PV Drivers Project both have quorum, but XAPI does not. It also says: "If none of the qualifying projects achieve a quorum, the change cannot hold. In that case, we consider that there is not enough momentum behind a change." That rule doesn’t apply to this situation, because we do have qualifying projects that have achieved a quorum. The phrasing seems to indicate that as long as *at least one* project qualifying project has a quorum, then the vote is valid. It then says: “For each qualifying project with a quorum, the percentage of votes in favour and against is calculated (e.g. if 5 people voted in favour, 2 against and 1 abstains, the share is 5/7th and 2/7th respectively).” That gives us: HV Project 100% (6/6), PV driver project 100% (1/1). Then it says: Votes in favour are averaged as percentages across all projects (say we have per project figures of 50%, 80%, 70% in favour, then the total vote in favour is 66.67%). That gives us: (100 + 100) / 2 == 100% Average And finally: "If the total vote achieves a 2/3rd majority in favour, the proposal passes. Otherwise it fails.” 100% > 2/3, so *according to my reading*, this passes. I’m going to wait a week before officially declaring it as having passed, however, to allow people to double-check my reading of the rules and propose alternate interpretations. -George [1] https://marc.info/?l=xen-devel&m=157928843015909&w=2 [2] https://xenproject.org/developers/governance/#project-decisions
[ovmf test] 153399: regressions - FAIL
flight 153399 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153399/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm 6 xen-buildfail REGR. vs. 152863
build-amd64 6 xen-buildfail REGR. vs. 152863
build-i3866 xen-buildfail REGR. vs. 152863
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 1 build-check(1) blocked n/a
build-i386-libvirt1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
version targeted for testing:
ovmf 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
baseline version:
ovmf 63d92674d240ab4ecab94f98e1e198842bb7de00
Last test of basis 152863 2020-08-26 16:09:47 Z5 days
Failing since152915 2020-08-27 18:09:42 Z4 days 87 attempts
Testing same since 153135 2020-08-30 02:28:59 Z1 days 31 attempts
People who touched revisions under test:
Laszlo Ersek
Paul
Paul G
jobs:
build-amd64-xsm fail
build-i386-xsm fail
build-amd64 fail
build-i386 fail
build-amd64-libvirt blocked
build-i386-libvirt blocked
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
test-amd64-i386-xl-qemuu-ovmf-amd64 blocked
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 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
Author: Paul
Date: Fri Aug 28 04:40:51 2020 +0800
MdePkg: Correcting EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT definition
In Acpi10.h, EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT is defined as 0x10,
but should be 0x02 per the ACPI Specification.
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2937
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Signed-off-by: Paul G
Reviewed-by: Liming Gao
commit cbccf995920a28071f5403b847f29ebf8b732fa9
Author: Laszlo Ersek
Date: Thu Aug 27 00:21:29 2020 +0200
OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just after SMI broadcast
The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick
succession -- it means a series of "device_add" QEMU monitor commands,
back-to-back.
If a "device_add" occurs *just after* ACPI raises the broadcast SMI, then:
- the CPU_FOREACH() loop in QEMU's ich9_apm_ctrl_changed() cannot make the
SMI pending for the new CPU -- at that time, the new CPU doesn't even
exist yet,
- OVMF will find the new CPU however (in the CPU hotplug register block),
in QemuCpuhpCollectApicIds().
As a result, when the firmware sends an INIT-SIPI-SIPI to the new CPU in
SmbaseRelocate(), expecting it to boot into SMM (due to the pending SMI),
the new CPU instead boots straight into the post-RSM (normal mode) "pen",
skipping its initial SMI handler.
The CPU halts nicely in the pen, but its SMBASE is never relocated, and
the SMRAM message exchange with the BSP falls apart -- the BSP gets stuck
in the following loop:
//
// Wait until the hot-added CPU is just about to execute RSM.
//
while (Context->AboutToLeaveSmm == 0) {
CpuPause ();
}
because the new CPU's initial SMI handler never sets the flag to nonzero.
Fix this by sending a directed SMI to the new CPU just before sending it
the INIT-SIPI-SIPI. The various scenarios are documented in the code --
the cases affected by the patch are documented under point (2).
Note that this is not considered a security patch, as for
[linux-linus test] 153385: regressions - FAIL
flight 153385 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/153385/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3866 xen-buildfail REGR. vs. 152332 build-amd64-xsm 6 xen-buildfail REGR. vs. 152332 build-amd64 6 xen-buildfail REGR. vs. 152332 build-i386-xsm6 xen-buildfail REGR. vs. 152332 Tests which did not succeed, but are not blocking: test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-examine 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd11-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd12-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64
Re: Golang design session follow-up
> On Aug 31, 2020, at 2:55 PM, Nick Rosbrook wrote: > > On Fri, Aug 28, 2020 at 07:05:08PM +, George Dunlap wrote: >> >> >>> On Aug 28, 2020, at 4:57 PM, George Dunlap wrote: >>> >>> >>> On Jul 21, 2020, at 1:35 AM, Nick Rosbrook wrote: # Long-term home of the package Ian: Autogenerated stuff is becoming more annoying. Delete all the libxl auto-generated stuff from staging & master, and have "output branch". The reason we have these in-tree is that otherwise you can't build *from git* if you don't have new enough versions of the right tools. Distribution: Make a repo on xenbits! >>> >>> So thinking about this: >>> >>> The first plan I had was to have a script in tools/golang/xenlight (and/or >>> the Makefile), which would be handed a directory, and would then: >>> >>> 1. Sync static files from tools/golang/xenlight into that directory >>> >>> 2. Run gengotypes.py, having the resulting generated files put into that >>> directory >>> >>> 3. Run `git diff` in the target directory; if there are any changes, then >>> automatically run `git commit` to check in the changes. >>> >>> That way you could just set up a cron job to sync things over on a regular >>> basis. >>> >>> Thinking about GPL considerations, however, you’d also want to include >>> libxl_types.idl and idl.py. And then of course, you should also include a >>> way to build the generated code from those two. >>> >>> At which point… would it make sense to just move the package out to its >>> separate repo entirely? I.e., have actual development happen in the repo >>> which ends up being cloned in the end? >>> >>> Obviously there are nice things about having the code in the same repo; but >>> there’s also something satisfying about being a full downstream. >>> >>> I was actually thinking it might make sense to put the repo at >>> https://gitlab.com/xen-project/go-xenlight , to try out that as a >>> development model. > Would that mean completely moving off of xen-devel for development? I can't > think of a huge reason why we wouldn't be able to do this if we wanted. I mean obviously the changes to libxl_types.idl and idl.py would have to happen on xen-devel; but yeah, changes to the external repo would happen within gitlab. >> >> I’ve put a sort of draft module up at https://gitlab.com/martyros/go-xen ; >> you can test it by adding the "gitlab.com/xen-project/go-xen/xenlight” >> package, but adding the following line to the go.mod of the test program: > I have a couple of patches I was going to send out on xen-devel today. I > could PR them to this repo instead (or in addition) if you want to try out > the gitlab workflow. Yeah, we could give that a try. -George
[PATCH v4 15/18] [automated] Use OBJECT_DECLARE_TYPE where possible
Replace DECLARE_OBJ_CHECKERS with OBJECT_DECLARE_TYPE where the typedefs can be safely removed. Generated running: $ ./scripts/codeconverter/converter.py -i \ --pattern=DeclareObjCheckers $(git grep -l '' -- '*.[ch]') Reviewed-by: Daniel P. Berrangé Signed-off-by: Eduardo Habkost --- Changes v3 -> v4: none Changes v2 -> v3: * Removed hunks due to rebase conflict: include/hw/ppc/xive.h include/hw/arm/armsse.h * Reviewed-by line from Daniel was kept, as no additional hunks are introduced in this version Changes v1 -> v2: * Script re-run after typedefs and macros were moved, and now the patch also touches: - TYPE_ARM_SSE - TYPE_SD_BUS Signed-off-by: Eduardo Habkost --- Cc: "Marc-André Lureau" Cc: Gerd Hoffmann Cc: "Michael S. Tsirkin" Cc: "Daniel P. Berrangé" Cc: Peter Maydell Cc: Corey Minyard Cc: "Cédric Le Goater" Cc: David Gibson Cc: Cornelia Huck Cc: Thomas Huth Cc: Halil Pasic Cc: Christian Borntraeger Cc: "Philippe Mathieu-Daudé" Cc: Alistair Francis Cc: David Hildenbrand Cc: Laurent Vivier Cc: Amit Shah Cc: Stefano Stabellini Cc: Anthony Perard Cc: Paul Durrant Cc: Paolo Bonzini Cc: Fam Zheng Cc: "Gonglei (Arei)" Cc: Eduardo Habkost Cc: Igor Mammedov Cc: Stefan Berger Cc: Richard Henderson Cc: Michael Rolnik Cc: Sarah Harris Cc: "Edgar E. Iglesias" Cc: Michael Walle Cc: Aleksandar Markovic Cc: Aurelien Jarno Cc: Jiaxun Yang Cc: Aleksandar Rikalo Cc: Anthony Green Cc: Chris Wulff Cc: Marek Vasut Cc: Stafford Horne Cc: Palmer Dabbelt Cc: Sagar Karandikar Cc: Bastian Koppelmann Cc: Yoshinori Sato Cc: Mark Cave-Ayland Cc: Artyom Tarasenko Cc: Guan Xuetao Cc: Max Filippov Cc: qemu-de...@nongnu.org Cc: qemu-...@nongnu.org Cc: qemu-...@nongnu.org Cc: qemu-s3...@nongnu.org Cc: qemu-bl...@nongnu.org Cc: xen-devel@lists.xenproject.org Cc: qemu-ri...@nongnu.org Signed-off-by: Eduardo Habkost --- hw/audio/intel-hda.h| 6 ++ hw/display/virtio-vga.h | 6 ++ include/authz/base.h| 6 ++ include/authz/list.h| 6 ++ include/authz/listfile.h| 6 ++ include/authz/pamacct.h | 6 ++ include/authz/simple.h | 6 ++ include/crypto/secret_common.h | 6 ++ include/crypto/secret_keyring.h | 6 ++ include/hw/hyperv/vmbus.h | 6 ++ include/hw/i2c/i2c.h| 6 ++ include/hw/i2c/smbus_slave.h| 6 ++ include/hw/ipack/ipack.h| 6 ++ include/hw/ipmi/ipmi.h | 6 ++ include/hw/mem/pc-dimm.h| 6 ++ include/hw/ppc/pnv.h| 6 ++ include/hw/ppc/pnv_core.h | 6 ++ include/hw/ppc/pnv_homer.h | 6 ++ include/hw/ppc/pnv_occ.h| 6 ++ include/hw/ppc/pnv_psi.h| 6 ++ include/hw/ppc/pnv_xive.h | 6 ++ include/hw/ppc/spapr_cpu_core.h | 6 ++ include/hw/ppc/spapr_drc.h | 6 ++ include/hw/ppc/spapr_vio.h | 6 ++ include/hw/ppc/spapr_xive.h | 6 ++ include/hw/ppc/xics.h | 6 ++ include/hw/s390x/event-facility.h | 6 ++ include/hw/s390x/s390_flic.h| 6 ++ include/hw/s390x/sclp.h | 6 ++ include/hw/sd/sd.h | 6 ++ include/hw/ssi/ssi.h| 6 ++ include/hw/sysbus.h | 6 ++ include/hw/virtio/virtio-gpu.h | 6 ++ include/hw/virtio/virtio-input.h| 6 ++ include/hw/virtio/virtio-mem.h | 6 ++ include/hw/virtio/virtio-pmem.h | 6 ++ include/hw/virtio/virtio-serial.h | 6 ++ include/hw/xen/xen-bus.h| 6 ++ include/io/channel.h| 6 ++ include/io/dns-resolver.h | 6 ++ include/io/net-listener.h | 6 ++ include/scsi/pr-manager.h | 6 ++ include/sysemu/cryptodev.h | 6 ++ include/sysemu/hostmem.h| 6 ++ include/sysemu/rng.h| 6 ++ include/sysemu/tpm_backend.h| 6 ++ include/sysemu/vhost-user-backend.h | 6 ++ target/alpha/cpu-qom.h | 6 ++ target/arm/cpu-qom.h| 6 ++ target/avr/cpu-qom.h| 6 ++ target/cris/cpu-qom.h | 6 ++ target/hppa/cpu-qom.h | 6 ++ target/i386/cpu-qom.h | 6 ++ target/lm32/cpu-qom.h | 6 ++ target/m68k/cpu-qom.h | 6 ++ target/microblaze/cpu-qom.h | 6 ++ target/mips/cpu-qom.h | 6 ++ target/moxie/cpu.h | 6 ++ target/nios2/cpu.h | 6 ++ target/openrisc/cpu.h | 6 ++ target/ppc/cpu-qom.h| 6 ++ target/riscv/cpu.h | 6 ++ target/s390x/cpu-qom.h | 6 ++ target/sh4/cpu-qom.h| 6 ++ target/sparc/cpu-qom.h
Re: [PATCH v4 1/2] memremap: rename MEMORY_DEVICE_DEVDAX to MEMORY_DEVICE_GENERIC
On Mon, Aug 31, 2020 at 12:19:07PM +0200, Roger Pau Monné wrote:
> On Thu, Aug 20, 2020 at 01:37:41PM +0200, Roger Pau Monné wrote:
> > On Tue, Aug 11, 2020 at 11:07:36PM +0200, David Hildenbrand wrote:
> > > On 11.08.20 11:44, Roger Pau Monne wrote:
> > > > This is in preparation for the logic behind MEMORY_DEVICE_DEVDAX also
> > > > being used by non DAX devices.
> > > >
> > > > No functional change intended.
> > > >
> > > > Signed-off-by: Roger Pau Monné
Dan is out on leave so I'll chime in.
I can't really justify keeping this as DEVDAX if there is another user who
needs the same type of mapping.
Sorry for the delay.
Reviewed-by: Ira Weiny
> > > > ---
> > > > Cc: Dan Williams
> > > > Cc: Vishal Verma
> > > > Cc: Dave Jiang
> > > > Cc: Andrew Morton
> > > > Cc: Jason Gunthorpe
> > > > Cc: Ira Weiny
> > > > Cc: "Aneesh Kumar K.V"
> > > > Cc: Johannes Thumshirn
> > > > Cc: Logan Gunthorpe
> > > > Cc: linux-nvd...@lists.01.org
> > > > Cc: xen-devel@lists.xenproject.org
> > > > Cc: linux...@kvack.org
> > > > ---
> > > > drivers/dax/device.c | 2 +-
> > > > include/linux/memremap.h | 9 -
> > > > mm/memremap.c| 2 +-
> > > > 3 files changed, 6 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/drivers/dax/device.c b/drivers/dax/device.c
> > > > index 4c0af2eb7e19..1e89513f3c59 100644
> > > > --- a/drivers/dax/device.c
> > > > +++ b/drivers/dax/device.c
> > > > @@ -429,7 +429,7 @@ int dev_dax_probe(struct device *dev)
> > > > return -EBUSY;
> > > > }
> > > >
> > > > - dev_dax->pgmap.type = MEMORY_DEVICE_DEVDAX;
> > > > + dev_dax->pgmap.type = MEMORY_DEVICE_GENERIC;
> > > > addr = devm_memremap_pages(dev, &dev_dax->pgmap);
> > > > if (IS_ERR(addr))
> > > > return PTR_ERR(addr);
> > > > diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> > > > index 5f5b2df06e61..e5862746751b 100644
> > > > --- a/include/linux/memremap.h
> > > > +++ b/include/linux/memremap.h
> > > > @@ -46,11 +46,10 @@ struct vmem_altmap {
> > > > * wakeup is used to coordinate physical address space management (ex:
> > > > * fs truncate/hole punch) vs pinned pages (ex: device dma).
> > > > *
> > > > - * MEMORY_DEVICE_DEVDAX:
> > > > + * MEMORY_DEVICE_GENERIC:
> > > > * Host memory that has similar access semantics as System RAM i.e. DMA
> > > > - * coherent and supports page pinning. In contrast to
> > > > - * MEMORY_DEVICE_FS_DAX, this memory is access via a device-dax
> > > > - * character device.
> > > > + * coherent and supports page pinning. This is for example used by DAX
> > > > devices
> > > > + * that expose memory using a character device.
> > > > *
> > > > * MEMORY_DEVICE_PCI_P2PDMA:
> > > > * Device memory residing in a PCI BAR intended for use with
> > > > Peer-to-Peer
> > > > @@ -60,7 +59,7 @@ enum memory_type {
> > > > /* 0 is reserved to catch uninitialized type fields */
> > > > MEMORY_DEVICE_PRIVATE = 1,
> > > > MEMORY_DEVICE_FS_DAX,
> > > > - MEMORY_DEVICE_DEVDAX,
> > > > + MEMORY_DEVICE_GENERIC,
> > > > MEMORY_DEVICE_PCI_P2PDMA,
> > > > };
> > > >
> > > > diff --git a/mm/memremap.c b/mm/memremap.c
> > > > index 03e38b7a38f1..006dace60b1a 100644
> > > > --- a/mm/memremap.c
> > > > +++ b/mm/memremap.c
> > > > @@ -216,7 +216,7 @@ void *memremap_pages(struct dev_pagemap *pgmap, int
> > > > nid)
> > > > return ERR_PTR(-EINVAL);
> > > > }
> > > > break;
> > > > - case MEMORY_DEVICE_DEVDAX:
> > > > + case MEMORY_DEVICE_GENERIC:
> > > > need_devmap_managed = false;
> > > > break;
> > > > case MEMORY_DEVICE_PCI_P2PDMA:
> > > >
> > >
> > > No strong opinion (@Dan?), I do wonder if a separate type would make
> > > sense.
> >
> > Gentle ping.
>
> Sorry to ping again, but I would rather get this out of my queue if
> possible, seeing as the other patch is OK to go in but depends on this
> one going in first.
>
> Thanks, Roger.
Re: [PATCH v2 8/8] x86/msr: Drop compatibility #GP handling in guest_{rd,wr}msr()
On Fri, Aug 28, 2020 at 10:55:29AM +0200, Jan Beulich wrote: > On 20.08.2020 17:08, Roger Pau Monne wrote: > > Now that the main PV/HVM MSR handlers raise #GP for all unknown MSRs, there > > is > > no need to special case these MSRs any more. > > I agree, yet I'd like to point out (based on past backporting of > security fixes) that this change may end up being a good source > of backporting mistakes, as 4.14 may need chunks added here which > on master / staging have no place anymore. Even if we leave this chunk out, patches for > 4.14 won't need to add anything to make a MSR return a #GP, so it's likely that the chunk will have to be added for backports anyway. I really have no idea of how to help with backporting with such change in place. Thanks, Roger.
Re: [PATCH v4 1/2] memremap: rename MEMORY_DEVICE_DEVDAX to MEMORY_DEVICE_GENERIC
On Tue, 11 Aug 2020 11:44:46 +0200 Roger Pau Monne wrote: > This is in preparation for the logic behind MEMORY_DEVICE_DEVDAX also > being used by non DAX devices. Acked-by: Andrew Morton . Please add it to the Xen tree when appropriate. (I'm not sure what David means by "separate type", but we can do that later if desired. Dan is taking a taking a bit of downtime).
Re: [PATCH v2 5/8] x86/pv: allow reading FEATURE_CONTROL MSR
On Thu, Aug 27, 2020 at 05:53:16PM +0200, Jan Beulich wrote: > On 20.08.2020 17:08, Roger Pau Monne wrote: > > @@ -181,6 +182,18 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t > > *val) > > /* Not offered to guests. */ > > goto gp_fault; > > > > +case MSR_IA32_FEATURE_CONTROL: > > +if ( !(cp->x86_vendor & X86_VENDOR_INTEL) ) > > +goto gp_fault; > > Can we really do it this way round, rather than raising #GP when > we know the MSR isn't there (AMD / Hygon)? I realized code e.g. > ... > > > +*val = IA32_FEATURE_CONTROL_LOCK; > > +if ( vmce_has_lmce(v) ) > > +*val |= IA32_FEATURE_CONTROL_LMCE_ON; > > +if ( nestedhvm_enabled(d) ) > > +*val |= IA32_FEATURE_CONTROL_ENABLE_VMXON_OUTSIDE_SMX; > > +break; > > + > > + > > case MSR_IA32_PLATFORM_ID: > > if ( !(cp->x86_vendor & X86_VENDOR_INTEL) || > > !(boot_cpu_data.x86_vendor & X86_VENDOR_INTEL) ) > > ... in context right here does it the same way, but I still > wonder whether we wouldn't better switch existing instances, too. Hm, no idea really. Right now it seems better to check for != Intel rather than AMD | Hygon | Centaur | Shanghai, as that's a MSR specific to Intel. Do those MSRs exist in Centaur / Shanghai? Thanks, Roger.
[qemu-mainline test] 153383: regressions - FAIL
flight 153383 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/153383/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3866 xen-buildfail REGR. vs. 152631 build-amd64-xsm 6 xen-buildfail REGR. vs. 152631 build-i386-xsm6 xen-buildfail REGR. vs. 152631 build-amd64 6 xen-buildfail REGR. vs. 152631 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 152631 test-armhf-armhf-xl-vhd 10 debian-di-installfail REGR. vs. 152631 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 152631 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 152631 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-rtds 12 guest-startfail pass in 153362 Tests which did not succeed, but are not blocking: test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd11-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd12-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dm
Re: [PATCH v2 2/8] x86/svm: silently drop writes to SYSCFG and related MSRs
On Mon, Aug 31, 2020 at 04:37:47PM +0200, Roger Pau Monné wrote: > On Thu, Aug 27, 2020 at 05:03:50PM +0200, Jan Beulich wrote: > > On 20.08.2020 17:08, Roger Pau Monne wrote: > > > --- a/xen/arch/x86/hvm/svm/svm.c > > > +++ b/xen/arch/x86/hvm/svm/svm.c > > > @@ -1917,6 +1917,21 @@ static int svm_msr_read_intercept(unsigned int > > > msr, uint64_t *msr_content) > > > goto gpf; > > > break; > > > > > > +case MSR_K8_TOP_MEM1: > > > +case MSR_K8_TOP_MEM2: > > > +*msr_content = 0; > > > +break; > > > > Any reason you don't fold this with ... > > > > > +case MSR_K8_SYSCFG: > > > +/* > > > + * Return MtrrFixDramEn: albeit the current emulated MTRR > > > + * implementation doesn't support the Extended Type-Field Format > > > having > > > + * such bit set is common on AMD hardware and is harmless as > > > long as > > > + * MtrrFixDramModEn isn't set. > > > + */ > > > +*msr_content = K8_MTRRFIXRANGE_DRAM_ENABLE; On the previous version you commented that returning 0 here would be more correct, do you still think so? I agree it seems better to not report any of those MTRR AMD specific features, since we don't implement them in our emulated MTRR code. Thanks, Roger.
Re: [PATCH v2 2/8] x86/svm: silently drop writes to SYSCFG and related MSRs
On Thu, Aug 27, 2020 at 05:03:50PM +0200, Jan Beulich wrote: > On 20.08.2020 17:08, Roger Pau Monne wrote: > > --- a/xen/arch/x86/hvm/svm/svm.c > > +++ b/xen/arch/x86/hvm/svm/svm.c > > @@ -1917,6 +1917,21 @@ static int svm_msr_read_intercept(unsigned int msr, > > uint64_t *msr_content) > > goto gpf; > > break; > > > > +case MSR_K8_TOP_MEM1: > > +case MSR_K8_TOP_MEM2: > > +*msr_content = 0; > > +break; > > Any reason you don't fold this with ... > > > +case MSR_K8_SYSCFG: > > +/* > > + * Return MtrrFixDramEn: albeit the current emulated MTRR > > + * implementation doesn't support the Extended Type-Field Format > > having > > + * such bit set is common on AMD hardware and is harmless as long > > as > > + * MtrrFixDramModEn isn't set. > > + */ > > +*msr_content = K8_MTRRFIXRANGE_DRAM_ENABLE; > > +break; > > + > > case MSR_K8_VM_CR: > > *msr_content = 0; > > break; > > ... this existing case, and ... I was trying to sort them by value, but I can certainly merge this and the case below. Thanks, Roger.
Re: [xen-unstable test] 153154: regressions - trouble: broken/fail/pass
On Mon, Aug 31, 2020 at 06:40:56AM +0200, Jürgen Groß wrote: > On 30.08.20 18:11, osstest service owner wrote: > > flight 153154 xen-unstable real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/153154/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including tests which could not be run: > > test-amd64-amd64-xl-qemut-debianhvm-i386-xsm > > broken > > test-amd64-amd64-xl-qemut-debianhvm-amd64 > > broken > > test-amd64-i386-xl-qemut-win7-amd64 broken > > test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 > > debian-hvm-install fail REGR. vs. 152877 > > test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 > > debian-hvm-install fail REGR. vs. 152877 > > Paul, I suspect some fallout from your hotplug/mtu series? > > The failure in > > http://logs.test-lab.xenproject.org/osstest/logs/153154/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/10.ts-debian-hvm-install.log > > is pointing in this direction IMO. There's a stubdom panic at: http://logs.test-lab.xenproject.org/osstest/logs/153154/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/godello0---var-log-xen-qemu-dm-debianhvm.guest.osstest.log No idea if it's related to the MTU stuff or not. Seems to happen during netfront initialization, so might be related. Roger.
Re: Ping: [PATCH v3 5/8] evtchn: add compat struct checking for newer sub-ops
On Mon, Aug 31, 2020 at 09:44:10AM +0200, Jan Beulich wrote: > On 23.07.2020 17:50, Jan Beulich wrote: > > Various additions to the interface did not get mirrored into the compat > > handling machinery. Luckily all additions were done in ways not making > > any form of translation necessary. > > > > Signed-off-by: Jan Beulich > > --- > > v3: New. > > Anyone? Reviewed-by: Roger Pau Monné Thanks, Roger.
[xen-unstable test] 153363: regressions - FAIL
flight 153363 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/153363/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 152877 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 152877 Tests which are failing intermittently (not blocking): test-amd64-i386-xl 21 guest-start.2fail in 153280 pass in 153363 test-armhf-armhf-xl-rtds 12 guest-start fail in 153321 pass in 153363 test-armhf-armhf-xl-rtds 17 guest-start.2 fail pass in 153280 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail pass in 153321 test-amd64-amd64-examine 4 memdisk-try-append fail pass in 153321 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 152877 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 152877 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 152877 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 152877 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 152877 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 152877 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 152877 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 152877 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 152877 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfai
[ovmf test] 153395: regressions - FAIL
flight 153395 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153395/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm 6 xen-buildfail REGR. vs. 152863
build-amd64 6 xen-buildfail REGR. vs. 152863
build-i3866 xen-buildfail REGR. vs. 152863
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 1 build-check(1) blocked n/a
build-i386-libvirt1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
version targeted for testing:
ovmf 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
baseline version:
ovmf 63d92674d240ab4ecab94f98e1e198842bb7de00
Last test of basis 152863 2020-08-26 16:09:47 Z5 days
Failing since152915 2020-08-27 18:09:42 Z3 days 86 attempts
Testing same since 153135 2020-08-30 02:28:59 Z1 days 30 attempts
People who touched revisions under test:
Laszlo Ersek
Paul
Paul G
jobs:
build-amd64-xsm fail
build-i386-xsm fail
build-amd64 fail
build-i386 fail
build-amd64-libvirt blocked
build-i386-libvirt blocked
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
test-amd64-i386-xl-qemuu-ovmf-amd64 blocked
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 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
Author: Paul
Date: Fri Aug 28 04:40:51 2020 +0800
MdePkg: Correcting EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT definition
In Acpi10.h, EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT is defined as 0x10,
but should be 0x02 per the ACPI Specification.
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2937
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Signed-off-by: Paul G
Reviewed-by: Liming Gao
commit cbccf995920a28071f5403b847f29ebf8b732fa9
Author: Laszlo Ersek
Date: Thu Aug 27 00:21:29 2020 +0200
OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just after SMI broadcast
The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick
succession -- it means a series of "device_add" QEMU monitor commands,
back-to-back.
If a "device_add" occurs *just after* ACPI raises the broadcast SMI, then:
- the CPU_FOREACH() loop in QEMU's ich9_apm_ctrl_changed() cannot make the
SMI pending for the new CPU -- at that time, the new CPU doesn't even
exist yet,
- OVMF will find the new CPU however (in the CPU hotplug register block),
in QemuCpuhpCollectApicIds().
As a result, when the firmware sends an INIT-SIPI-SIPI to the new CPU in
SmbaseRelocate(), expecting it to boot into SMM (due to the pending SMI),
the new CPU instead boots straight into the post-RSM (normal mode) "pen",
skipping its initial SMI handler.
The CPU halts nicely in the pen, but its SMBASE is never relocated, and
the SMRAM message exchange with the BSP falls apart -- the BSP gets stuck
in the following loop:
//
// Wait until the hot-added CPU is just about to execute RSM.
//
while (Context->AboutToLeaveSmm == 0) {
CpuPause ();
}
because the new CPU's initial SMI handler never sets the flag to nonzero.
Fix this by sending a directed SMI to the new CPU just before sending it
the INIT-SIPI-SIPI. The various scenarios are documented in the code --
the cases affected by the patch are documented under point (2).
Note that this is not considered a security patch, as for
[xen-unstable-smoke test] 153382: tolerable all pass - PUSHED
flight 153382 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/153382/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen afe018e041ec112d90a8b4e6ed607d22aa06f280 baseline version: xen d400dc5729e4e132d61c2e7df57d81aaed762044 Last test of basis 152976 2020-08-28 10:01:16 Z3 days Testing same since 153382 2020-08-31 14:00:27 Z0 days1 attempts People who touched revisions under test: Andrew Cooper jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass 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 : To xenbits.xen.org:/home/xen/git/xen.git d400dc5729..afe018e041 afe018e041ec112d90a8b4e6ed607d22aa06f280 -> smoke
[ovmf test] 153379: regressions - FAIL
flight 153379 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153379/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm 6 xen-buildfail REGR. vs. 152863
build-amd64 6 xen-buildfail REGR. vs. 152863
build-i3866 xen-buildfail REGR. vs. 152863
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 1 build-check(1) blocked n/a
build-i386-libvirt1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
version targeted for testing:
ovmf 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
baseline version:
ovmf 63d92674d240ab4ecab94f98e1e198842bb7de00
Last test of basis 152863 2020-08-26 16:09:47 Z4 days
Failing since152915 2020-08-27 18:09:42 Z3 days 85 attempts
Testing same since 153135 2020-08-30 02:28:59 Z1 days 29 attempts
People who touched revisions under test:
Laszlo Ersek
Paul
Paul G
jobs:
build-amd64-xsm fail
build-i386-xsm fail
build-amd64 fail
build-i386 fail
build-amd64-libvirt blocked
build-i386-libvirt blocked
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
test-amd64-i386-xl-qemuu-ovmf-amd64 blocked
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 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
Author: Paul
Date: Fri Aug 28 04:40:51 2020 +0800
MdePkg: Correcting EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT definition
In Acpi10.h, EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT is defined as 0x10,
but should be 0x02 per the ACPI Specification.
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2937
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Signed-off-by: Paul G
Reviewed-by: Liming Gao
commit cbccf995920a28071f5403b847f29ebf8b732fa9
Author: Laszlo Ersek
Date: Thu Aug 27 00:21:29 2020 +0200
OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just after SMI broadcast
The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick
succession -- it means a series of "device_add" QEMU monitor commands,
back-to-back.
If a "device_add" occurs *just after* ACPI raises the broadcast SMI, then:
- the CPU_FOREACH() loop in QEMU's ich9_apm_ctrl_changed() cannot make the
SMI pending for the new CPU -- at that time, the new CPU doesn't even
exist yet,
- OVMF will find the new CPU however (in the CPU hotplug register block),
in QemuCpuhpCollectApicIds().
As a result, when the firmware sends an INIT-SIPI-SIPI to the new CPU in
SmbaseRelocate(), expecting it to boot into SMM (due to the pending SMI),
the new CPU instead boots straight into the post-RSM (normal mode) "pen",
skipping its initial SMI handler.
The CPU halts nicely in the pen, but its SMBASE is never relocated, and
the SMRAM message exchange with the BSP falls apart -- the BSP gets stuck
in the following loop:
//
// Wait until the hot-added CPU is just about to execute RSM.
//
while (Context->AboutToLeaveSmm == 0) {
CpuPause ();
}
because the new CPU's initial SMI handler never sets the flag to nonzero.
Fix this by sending a directed SMI to the new CPU just before sending it
the INIT-SIPI-SIPI. The various scenarios are documented in the code --
the cases affected by the patch are documented under point (2).
Note that this is not considered a security patch, as for
[PATCH AUTOSEL 4.14 9/9] xen/xenbus: Fix granting of vmalloc'd memory
From: Simon Leiner
[ Upstream commit d742db70033c745e410523e00522ee0cfe2aa416 ]
On some architectures (like ARM), virt_to_gfn cannot be used for
vmalloc'd memory because of its reliance on virt_to_phys. This patch
introduces a check for vmalloc'd addresses and obtains the PFN using
vmalloc_to_pfn in that case.
Signed-off-by: Simon Leiner
Reviewed-by: Stefano Stabellini
Link: https://lore.kernel.org/r/20200825093153.35500-1-si...@leiner.me
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
drivers/xen/xenbus/xenbus_client.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index e94a61eaeceb0..f7b553faadb10 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -365,8 +365,14 @@ int xenbus_grant_ring(struct xenbus_device *dev, void
*vaddr,
int i, j;
for (i = 0; i < nr_pages; i++) {
- err = gnttab_grant_foreign_access(dev->otherend_id,
- virt_to_gfn(vaddr), 0);
+ unsigned long gfn;
+
+ if (is_vmalloc_addr(vaddr))
+ gfn = pfn_to_gfn(vmalloc_to_pfn(vaddr));
+ else
+ gfn = virt_to_gfn(vaddr);
+
+ err = gnttab_grant_foreign_access(dev->otherend_id, gfn, 0);
if (err < 0) {
xenbus_dev_fatal(dev, err,
"granting access to ring page");
--
2.25.1
[PATCH AUTOSEL 4.19 11/11] xen/xenbus: Fix granting of vmalloc'd memory
From: Simon Leiner
[ Upstream commit d742db70033c745e410523e00522ee0cfe2aa416 ]
On some architectures (like ARM), virt_to_gfn cannot be used for
vmalloc'd memory because of its reliance on virt_to_phys. This patch
introduces a check for vmalloc'd addresses and obtains the PFN using
vmalloc_to_pfn in that case.
Signed-off-by: Simon Leiner
Reviewed-by: Stefano Stabellini
Link: https://lore.kernel.org/r/20200825093153.35500-1-si...@leiner.me
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
drivers/xen/xenbus/xenbus_client.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index e94a61eaeceb0..f7b553faadb10 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -365,8 +365,14 @@ int xenbus_grant_ring(struct xenbus_device *dev, void
*vaddr,
int i, j;
for (i = 0; i < nr_pages; i++) {
- err = gnttab_grant_foreign_access(dev->otherend_id,
- virt_to_gfn(vaddr), 0);
+ unsigned long gfn;
+
+ if (is_vmalloc_addr(vaddr))
+ gfn = pfn_to_gfn(vmalloc_to_pfn(vaddr));
+ else
+ gfn = virt_to_gfn(vaddr);
+
+ err = gnttab_grant_foreign_access(dev->otherend_id, gfn, 0);
if (err < 0) {
xenbus_dev_fatal(dev, err,
"granting access to ring page");
--
2.25.1
[PATCH AUTOSEL 4.9 6/6] xen/xenbus: Fix granting of vmalloc'd memory
From: Simon Leiner
[ Upstream commit d742db70033c745e410523e00522ee0cfe2aa416 ]
On some architectures (like ARM), virt_to_gfn cannot be used for
vmalloc'd memory because of its reliance on virt_to_phys. This patch
introduces a check for vmalloc'd addresses and obtains the PFN using
vmalloc_to_pfn in that case.
Signed-off-by: Simon Leiner
Reviewed-by: Stefano Stabellini
Link: https://lore.kernel.org/r/20200825093153.35500-1-si...@leiner.me
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
drivers/xen/xenbus/xenbus_client.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index df27cefb2fa35..266f446ba331c 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -384,8 +384,14 @@ int xenbus_grant_ring(struct xenbus_device *dev, void
*vaddr,
int i, j;
for (i = 0; i < nr_pages; i++) {
- err = gnttab_grant_foreign_access(dev->otherend_id,
- virt_to_gfn(vaddr), 0);
+ unsigned long gfn;
+
+ if (is_vmalloc_addr(vaddr))
+ gfn = pfn_to_gfn(vmalloc_to_pfn(vaddr));
+ else
+ gfn = virt_to_gfn(vaddr);
+
+ err = gnttab_grant_foreign_access(dev->otherend_id, gfn, 0);
if (err < 0) {
xenbus_dev_fatal(dev, err,
"granting access to ring page");
--
2.25.1
[PATCH AUTOSEL 4.4 5/5] xen/xenbus: Fix granting of vmalloc'd memory
From: Simon Leiner
[ Upstream commit d742db70033c745e410523e00522ee0cfe2aa416 ]
On some architectures (like ARM), virt_to_gfn cannot be used for
vmalloc'd memory because of its reliance on virt_to_phys. This patch
introduces a check for vmalloc'd addresses and obtains the PFN using
vmalloc_to_pfn in that case.
Signed-off-by: Simon Leiner
Reviewed-by: Stefano Stabellini
Link: https://lore.kernel.org/r/20200825093153.35500-1-si...@leiner.me
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
drivers/xen/xenbus/xenbus_client.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index df27cefb2fa35..266f446ba331c 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -384,8 +384,14 @@ int xenbus_grant_ring(struct xenbus_device *dev, void
*vaddr,
int i, j;
for (i = 0; i < nr_pages; i++) {
- err = gnttab_grant_foreign_access(dev->otherend_id,
- virt_to_gfn(vaddr), 0);
+ unsigned long gfn;
+
+ if (is_vmalloc_addr(vaddr))
+ gfn = pfn_to_gfn(vmalloc_to_pfn(vaddr));
+ else
+ gfn = virt_to_gfn(vaddr);
+
+ err = gnttab_grant_foreign_access(dev->otherend_id, gfn, 0);
if (err < 0) {
xenbus_dev_fatal(dev, err,
"granting access to ring page");
--
2.25.1
[PATCH AUTOSEL 5.4 22/23] xen/xenbus: Fix granting of vmalloc'd memory
From: Simon Leiner
[ Upstream commit d742db70033c745e410523e00522ee0cfe2aa416 ]
On some architectures (like ARM), virt_to_gfn cannot be used for
vmalloc'd memory because of its reliance on virt_to_phys. This patch
introduces a check for vmalloc'd addresses and obtains the PFN using
vmalloc_to_pfn in that case.
Signed-off-by: Simon Leiner
Reviewed-by: Stefano Stabellini
Link: https://lore.kernel.org/r/20200825093153.35500-1-si...@leiner.me
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
drivers/xen/xenbus/xenbus_client.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index a38292ef79f6d..f38bdaea0ef11 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -363,8 +363,14 @@ int xenbus_grant_ring(struct xenbus_device *dev, void
*vaddr,
int i, j;
for (i = 0; i < nr_pages; i++) {
- err = gnttab_grant_foreign_access(dev->otherend_id,
- virt_to_gfn(vaddr), 0);
+ unsigned long gfn;
+
+ if (is_vmalloc_addr(vaddr))
+ gfn = pfn_to_gfn(vmalloc_to_pfn(vaddr));
+ else
+ gfn = virt_to_gfn(vaddr);
+
+ err = gnttab_grant_foreign_access(dev->otherend_id, gfn, 0);
if (err < 0) {
xenbus_dev_fatal(dev, err,
"granting access to ring page");
--
2.25.1
[PATCH AUTOSEL 5.8 41/42] xen/xenbus: Fix granting of vmalloc'd memory
From: Simon Leiner
[ Upstream commit d742db70033c745e410523e00522ee0cfe2aa416 ]
On some architectures (like ARM), virt_to_gfn cannot be used for
vmalloc'd memory because of its reliance on virt_to_phys. This patch
introduces a check for vmalloc'd addresses and obtains the PFN using
vmalloc_to_pfn in that case.
Signed-off-by: Simon Leiner
Reviewed-by: Stefano Stabellini
Link: https://lore.kernel.org/r/20200825093153.35500-1-si...@leiner.me
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
drivers/xen/xenbus/xenbus_client.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index 786fbb7d8be06..907bcbb93afbf 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -379,8 +379,14 @@ int xenbus_grant_ring(struct xenbus_device *dev, void
*vaddr,
int i, j;
for (i = 0; i < nr_pages; i++) {
- err = gnttab_grant_foreign_access(dev->otherend_id,
- virt_to_gfn(vaddr), 0);
+ unsigned long gfn;
+
+ if (is_vmalloc_addr(vaddr))
+ gfn = pfn_to_gfn(vmalloc_to_pfn(vaddr));
+ else
+ gfn = virt_to_gfn(vaddr);
+
+ err = gnttab_grant_foreign_access(dev->otherend_id, gfn, 0);
if (err < 0) {
xenbus_dev_fatal(dev, err,
"granting access to ring page");
--
2.25.1
Re: [PATCH v2 5/8] x86/pv: allow reading FEATURE_CONTROL MSR
On 31.08.2020 17:12, Roger Pau Monné wrote: > On Thu, Aug 27, 2020 at 05:53:16PM +0200, Jan Beulich wrote: >> On 20.08.2020 17:08, Roger Pau Monne wrote: >>> @@ -181,6 +182,18 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t >>> *val) >>> /* Not offered to guests. */ >>> goto gp_fault; >>> >>> +case MSR_IA32_FEATURE_CONTROL: >>> +if ( !(cp->x86_vendor & X86_VENDOR_INTEL) ) >>> +goto gp_fault; >> >> Can we really do it this way round, rather than raising #GP when >> we know the MSR isn't there (AMD / Hygon)? I realized code e.g. >> ... >> >>> +*val = IA32_FEATURE_CONTROL_LOCK; >>> +if ( vmce_has_lmce(v) ) >>> +*val |= IA32_FEATURE_CONTROL_LMCE_ON; >>> +if ( nestedhvm_enabled(d) ) >>> +*val |= IA32_FEATURE_CONTROL_ENABLE_VMXON_OUTSIDE_SMX; >>> +break; >>> + >>> + >>> case MSR_IA32_PLATFORM_ID: >>> if ( !(cp->x86_vendor & X86_VENDOR_INTEL) || >>> !(boot_cpu_data.x86_vendor & X86_VENDOR_INTEL) ) >> >> ... in context right here does it the same way, but I still >> wonder whether we wouldn't better switch existing instances, too. > > Hm, no idea really. Right now it seems better to check for != Intel > rather than AMD | Hygon | Centaur | Shanghai, as that's a MSR specific > to Intel. > > Do those MSRs exist in Centaur / Shanghai? I can't tell for sure, but I suppose they do, as they're (in a way) cloning Intel's implementation. My thinking here is that by not exposing an MSR when we should we potentially cause guests to crash. Whereas by exposing an MSR that ought not be there fallout would result only if the vendor actually has something else at that index. And I'd hope vendors apply some care to avoid doing so. Jan
Re: [PATCH v2 2/8] x86/svm: silently drop writes to SYSCFG and related MSRs
On 31.08.2020 16:45, Roger Pau Monné wrote: > On Mon, Aug 31, 2020 at 04:37:47PM +0200, Roger Pau Monné wrote: >> On Thu, Aug 27, 2020 at 05:03:50PM +0200, Jan Beulich wrote: >>> On 20.08.2020 17:08, Roger Pau Monne wrote: --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -1917,6 +1917,21 @@ static int svm_msr_read_intercept(unsigned int msr, uint64_t *msr_content) goto gpf; break; +case MSR_K8_TOP_MEM1: +case MSR_K8_TOP_MEM2: +*msr_content = 0; +break; >>> >>> Any reason you don't fold this with ... >>> +case MSR_K8_SYSCFG: +/* + * Return MtrrFixDramEn: albeit the current emulated MTRR + * implementation doesn't support the Extended Type-Field Format having + * such bit set is common on AMD hardware and is harmless as long as + * MtrrFixDramModEn isn't set. + */ +*msr_content = K8_MTRRFIXRANGE_DRAM_ENABLE; > > On the previous version you commented that returning 0 here would be > more correct, do you still think so? I do, but I'm still hoping to either get Andrew to agree (iirc it was him to suggest the value above), or for me to understand why he's wanting it this way. Jan
Re: [PATCH v2 2/8] x86/svm: silently drop writes to SYSCFG and related MSRs
On 31.08.2020 16:37, Roger Pau Monné wrote: > On Thu, Aug 27, 2020 at 05:03:50PM +0200, Jan Beulich wrote: >> On 20.08.2020 17:08, Roger Pau Monne wrote: >>> --- a/xen/arch/x86/hvm/svm/svm.c >>> +++ b/xen/arch/x86/hvm/svm/svm.c >>> @@ -1917,6 +1917,21 @@ static int svm_msr_read_intercept(unsigned int msr, >>> uint64_t *msr_content) >>> goto gpf; >>> break; >>> >>> +case MSR_K8_TOP_MEM1: >>> +case MSR_K8_TOP_MEM2: >>> +*msr_content = 0; >>> +break; >> >> Any reason you don't fold this with ... >> >>> +case MSR_K8_SYSCFG: >>> +/* >>> + * Return MtrrFixDramEn: albeit the current emulated MTRR >>> + * implementation doesn't support the Extended Type-Field Format >>> having >>> + * such bit set is common on AMD hardware and is harmless as long >>> as >>> + * MtrrFixDramModEn isn't set. >>> + */ >>> +*msr_content = K8_MTRRFIXRANGE_DRAM_ENABLE; >>> +break; >>> + >>> case MSR_K8_VM_CR: >>> *msr_content = 0; >>> break; >> >> ... this existing case, and ... > > I was trying to sort them by value, but I can certainly merge this and > the case below. Sorting by number is helpful as a secondary criteria, but I think groups of registers wanting to be handled the same should go together. This is especially looking forward, where otherwise many instances of the same (trivial or not) logic may appear. Jan
[PATCH] x86/pv: Fix multiple bugs with SEGBASE_GS_USER_SEL
The logic takes the segment selector unmodified from guest context. This
allowed the guest to load DPL0 descriptors into %gs. Fix up the RPL for
non-NUL selectors to be 3.
Xen's context switch logic skips saving the inactive %gs base, as it cannot be
modified by the guest behind Xen's back. This depends on Xen caching updates
to the inactive base, which is was missing from this path.
The consequence is that, following SEGBASE_GS_USER_SEL, the next context
switch will restore the stale inactive %gs base, and corrupt vcpu state.
Rework the hypercall to update the cached idea of gs_base_user, and fix the
behaviour in the case of the AMD NUL selector bug to always zero the segment
base.
Reported-by: Andy Lutomirski
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Andy Lutomirski
---
xen/arch/x86/x86_64/mm.c | 56 +++-
1 file changed, 46 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 29048d34dc..95ee05cd5d 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -1059,16 +1059,52 @@ long do_set_segment_base(unsigned int which, unsigned
long base)
break;
case SEGBASE_GS_USER_SEL:
-__asm__ __volatile__ (
-" swapgs \n"
-"1: movl %k0,%%gs \n"
-""safe_swapgs"\n"
-".section .fixup,\"ax\" \n"
-"2: xorl %k0,%k0\n"
-" jmp 1b \n"
-".previous\n"
-_ASM_EXTABLE(1b, 2b)
-: "+r" (base) );
+/*
+ * We wish to update the user %gs from the GDT/LDT. Currently, the
+ * guest kernel's GS_BASE is in context.
+ */
+asm volatile ( "swapgs" );
+
+if ( base <= 3 )
+{
+/* Work around NUL segment behaviour on AMD hardware. */
+if ( boot_cpu_data.x86_vendor &
+ (X86_VENDOR_AMD | X86_VENDOR_HYGON) )
+asm volatile ( "mov %[sel], %%gs"
+ :: [sel] "rm" (FLAT_USER_DS32) );
+}
+else
+/* Fix up RPL. */
+base |= 3;
+
+/*
+ * Load the chosen selector, with fault handling.
+ *
+ * Errors ought to fail the hypercall, but that was never built in
+ * originally, and Linux will BUG() if this call fails.
+ *
+ * NUL the selector in the case of an error. This too needs to deal
+ * with the AMD NUL segment behaviour, but it is already a slowpath in
+ * #GP context so perform the flat load unconditionally to avoid
+ * complicated logic.
+ *
+ * Anyone wanting to check for errors from this hypercall should
+ * re-read %gs and compare against the input 'base' selector.
+ */
+asm volatile ( "1: mov %k[sel], %%gs\n\t"
+ ".section .fixup, \"ax\", @progbits\n\t"
+ "2: mov %k[flat], %%gs\n\t"
+ " xor %k[sel], %k[sel]\n\t"
+ " jmp 1b\n\t"
+ ".previous\n\t"
+ _ASM_EXTABLE(1b, 2b)
+ : [sel] "+r" (base)
+ : [flat] "rm" (FLAT_USER_DS32) );
+
+/* Update the cache of the inactive base, as read from the GDT/LDT. */
+v->arch.pv.gs_base_user = rdgsbase();
+
+asm volatile ( safe_swapgs );
break;
default:
--
2.11.0
Re: [patch V2 46/46] irqchip: Add IMS (Interrupt Message Storm) driver - NOT FOR MERGING
On Wed, Aug 26, 2020 at 01:17:14PM +0200, Thomas Gleixner wrote: > + * ims_queue_info - Information to create an IMS queue domain > + * @queue_lock: Callback which informs the device driver that > + * an interrupt management operation starts. > + * @queue_sync_unlock: Callback which informs the device driver that an > + * interrupt management operation ends. > + > + * @queue_get_shadow: Callback to retrieve te shadow storage for a MSI > + * entry associated to a queue. The queue is > + * identified by the device struct which is used for > + * allocating interrupts and the msi entry index. > + * > + * @queue_lock() and @queue_sync_unlock() are only called for management > + * operations on a particular interrupt: request, free, enable, disable, > + * affinity setting. These functions are never called from atomic context, > + * like low level interrupt handling code. The purpose of these functions > + * is to signal the device driver the start and end of an operation which > + * affects the IMS queue shadow state. @queue_lock() allows the driver to > + * do preperatory work, e.g. locking. Note, that @queue_lock() has to > + * preserve the sleepable state on return. That means the driver cannot > + * disable preemption and (soft)interrupts in @queue_lock and then undo > + * that operation in @queue_sync_unlock() which restricts the lock types > + * for eventual serialization of these operations to sleepable locks. Of > + * course the driver can disable preemption and (soft)interrupts > + * temporarily for internal work. > + * > + * On @queue_sync_unlock() the driver has to check whether the shadow state > + * changed and issue a command to update the hardware state and wait for > + * the command to complete. If the command fails or times out then the > + * driver has to take care of the resulting mess as this is called from > + * functions which have no return value and none of the callers can deal > + * with the failure. The lock which is used by the driver to protect a > + * operation sequence must obviously not be released before the command > + * completes or fails. Otherwise new operations on the same interrupt line > + * could take place and change the shadow state before the driver was able > + * to compose the command. I haven't looked through everything in detail, but this does look like it is good for the mlx5 devices. Looked like it was only one small update to the set_affinity, so not very disruptive? Thanks, Jason
Re: [patch V2 24/46] PCI: vmd: Mark VMD irqdomain with DOMAIN_BUS_VMD_MSI
On Wed, Aug 26, 2020 at 01:16:52PM +0200, Thomas Gleixner wrote: > From: Thomas Gleixner > > Devices on the VMD bus use their own MSI irq domain, but it is not > distinguishable from regular PCI/MSI irq domains. This is required > to exclude VMD devices from getting the irq domain pointer set by > interrupt remapping. > > Override the default bus token. > > Signed-off-by: Thomas Gleixner > Acked-by: Bjorn Helgaas > drivers/pci/controller/vmd.c |6 ++ > 1 file changed, 6 insertions(+) > > +++ b/drivers/pci/controller/vmd.c > @@ -579,6 +579,12 @@ static int vmd_enable_domain(struct vmd_ > return -ENODEV; > } > > + /* > + * Override the irq domain bus token so the domain can be distinguished > + * from a regular PCI/MSI domain. > + */ > + irq_domain_update_bus_token(vmd->irq_domain, DOMAIN_BUS_VMD_MSI); > + Having the non-transparent-bridge hold a MSI table and multiplex/de-multiplex IRQs looks like another good use case for something close to pci_subdevice_msi_create_irq_domain()? If each device could have its own internal MSI-X table programmed properly things would work alot better. Disable capture/remap of the MSI range in the NTB. Then each device could have a proper non-multiplexed interrupt delivered to the CPU.. Affinity would work properly, no need to share IRQs (eg vmd_irq() goes away)/etc. Something for the VMD maintainers to think about at least. As I hear more about NTB these days a full MSI scheme for NTB seems interesting to have in the PCI-E core code.. Jason
Re: [xen-unstable test] 153154: regressions - trouble: broken/fail/pass
On 31.08.2020 16:23, Roger Pau Monné wrote: > On Mon, Aug 31, 2020 at 06:40:56AM +0200, Jürgen Groß wrote: >> On 30.08.20 18:11, osstest service owner wrote: >>> flight 153154 xen-unstable real [real] >>> http://logs.test-lab.xenproject.org/osstest/logs/153154/ >>> >>> Regressions :-( >>> >>> Tests which did not succeed and are blocking, >>> including tests which could not be run: >>> test-amd64-amd64-xl-qemut-debianhvm-i386-xsm >>> broken >>> test-amd64-amd64-xl-qemut-debianhvm-amd64 >>> broken >>> test-amd64-i386-xl-qemut-win7-amd64 broken >>> test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 >>> debian-hvm-install fail REGR. vs. 152877 >>> test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 >>> debian-hvm-install fail REGR. vs. 152877 >> >> Paul, I suspect some fallout from your hotplug/mtu series? >> >> The failure in >> >> http://logs.test-lab.xenproject.org/osstest/logs/153154/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/10.ts-debian-hvm-install.log >> >> is pointing in this direction IMO. > > There's a stubdom panic at: > > http://logs.test-lab.xenproject.org/osstest/logs/153154/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/godello0---var-log-xen-qemu-dm-debianhvm.guest.osstest.log > > No idea if it's related to the MTU stuff or not. Seems to happen during > netfront initialization, so might be related. Might also be the netfront_init() changes in / for mini-os then. Jan
Re: [PATCH v4 1/2] memremap: rename MEMORY_DEVICE_DEVDAX to MEMORY_DEVICE_GENERIC
On Thu, Aug 20, 2020 at 01:37:41PM +0200, Roger Pau Monné wrote:
> On Tue, Aug 11, 2020 at 11:07:36PM +0200, David Hildenbrand wrote:
> > On 11.08.20 11:44, Roger Pau Monne wrote:
> > > This is in preparation for the logic behind MEMORY_DEVICE_DEVDAX also
> > > being used by non DAX devices.
> > >
> > > No functional change intended.
> > >
> > > Signed-off-by: Roger Pau Monné
> > > ---
> > > Cc: Dan Williams
> > > Cc: Vishal Verma
> > > Cc: Dave Jiang
> > > Cc: Andrew Morton
> > > Cc: Jason Gunthorpe
> > > Cc: Ira Weiny
> > > Cc: "Aneesh Kumar K.V"
> > > Cc: Johannes Thumshirn
> > > Cc: Logan Gunthorpe
> > > Cc: linux-nvd...@lists.01.org
> > > Cc: xen-devel@lists.xenproject.org
> > > Cc: linux...@kvack.org
> > > ---
> > > drivers/dax/device.c | 2 +-
> > > include/linux/memremap.h | 9 -
> > > mm/memremap.c| 2 +-
> > > 3 files changed, 6 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/dax/device.c b/drivers/dax/device.c
> > > index 4c0af2eb7e19..1e89513f3c59 100644
> > > --- a/drivers/dax/device.c
> > > +++ b/drivers/dax/device.c
> > > @@ -429,7 +429,7 @@ int dev_dax_probe(struct device *dev)
> > > return -EBUSY;
> > > }
> > >
> > > - dev_dax->pgmap.type = MEMORY_DEVICE_DEVDAX;
> > > + dev_dax->pgmap.type = MEMORY_DEVICE_GENERIC;
> > > addr = devm_memremap_pages(dev, &dev_dax->pgmap);
> > > if (IS_ERR(addr))
> > > return PTR_ERR(addr);
> > > diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> > > index 5f5b2df06e61..e5862746751b 100644
> > > --- a/include/linux/memremap.h
> > > +++ b/include/linux/memremap.h
> > > @@ -46,11 +46,10 @@ struct vmem_altmap {
> > > * wakeup is used to coordinate physical address space management (ex:
> > > * fs truncate/hole punch) vs pinned pages (ex: device dma).
> > > *
> > > - * MEMORY_DEVICE_DEVDAX:
> > > + * MEMORY_DEVICE_GENERIC:
> > > * Host memory that has similar access semantics as System RAM i.e. DMA
> > > - * coherent and supports page pinning. In contrast to
> > > - * MEMORY_DEVICE_FS_DAX, this memory is access via a device-dax
> > > - * character device.
> > > + * coherent and supports page pinning. This is for example used by DAX
> > > devices
> > > + * that expose memory using a character device.
> > > *
> > > * MEMORY_DEVICE_PCI_P2PDMA:
> > > * Device memory residing in a PCI BAR intended for use with Peer-to-Peer
> > > @@ -60,7 +59,7 @@ enum memory_type {
> > > /* 0 is reserved to catch uninitialized type fields */
> > > MEMORY_DEVICE_PRIVATE = 1,
> > > MEMORY_DEVICE_FS_DAX,
> > > - MEMORY_DEVICE_DEVDAX,
> > > + MEMORY_DEVICE_GENERIC,
> > > MEMORY_DEVICE_PCI_P2PDMA,
> > > };
> > >
> > > diff --git a/mm/memremap.c b/mm/memremap.c
> > > index 03e38b7a38f1..006dace60b1a 100644
> > > --- a/mm/memremap.c
> > > +++ b/mm/memremap.c
> > > @@ -216,7 +216,7 @@ void *memremap_pages(struct dev_pagemap *pgmap, int
> > > nid)
> > > return ERR_PTR(-EINVAL);
> > > }
> > > break;
> > > - case MEMORY_DEVICE_DEVDAX:
> > > + case MEMORY_DEVICE_GENERIC:
> > > need_devmap_managed = false;
> > > break;
> > > case MEMORY_DEVICE_PCI_P2PDMA:
> > >
> >
> > No strong opinion (@Dan?), I do wonder if a separate type would make sense.
>
> Gentle ping.
Sorry to ping again, but I would rather get this out of my queue if
possible, seeing as the other patch is OK to go in but depends on this
one going in first.
Thanks, Roger.
Re: [PATCH] gitignore: Move ignores from global to subdirectories
> On Aug 31, 2020, at 7:37 AM, Elliott Mitchell wrote: > > On Fri, Aug 28, 2020 at 09:24:41AM +0200, Jan Beulich wrote: >> On 28.08.2020 04:57, Elliott Mitchell wrote: >>> Subdirectories which have .gitignore files should not be referenced in >>> the global .gitignore files. Move several lines to appropriate subdirs. >>> >>> Signed-off-by: Elliott Mitchell >>> >>> --- >>> Hopefully the commit message covers it. When moved to the subdirectories >>> I'm using "./" as otherwise any file sharing the name in a deeper >>> subdirectory would be subject to the match. >> >> May I ask why this last sentence isn't part of the commit message? > > My thinking is it was pretty straightforward to figure out when looking. > Not /quite/ obvious enough to avoid commenting in e-mail, but not quite > obscure enough to have in commit message. This can go either way really. Storing the extra paragraph in git is cheap; trying to reconstruct why someone made a change 10 years after the fact is often difficult. Probably not worth a re-send — it can be moved into the commit message by the committer; but if you’re going to send v2 anyway, might as well move it in. -George
[qemu-mainline test] 153362: regressions - FAIL
flight 153362 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/153362/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3866 xen-buildfail REGR. vs. 152631 build-amd64-xsm 6 xen-buildfail REGR. vs. 152631 build-i386-xsm6 xen-buildfail REGR. vs. 152631 build-amd64 6 xen-buildfail REGR. vs. 152631 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 152631 test-armhf-armhf-xl-vhd 10 debian-di-installfail REGR. vs. 152631 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 152631 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 152631 Tests which did not succeed, but are not blocking: test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd11-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd12-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
[linux-linus test] 153359: regressions - FAIL
flight 153359 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/153359/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3866 xen-buildfail REGR. vs. 152332 build-amd64-xsm 6 xen-buildfail REGR. vs. 152332 build-amd64 6 xen-buildfail REGR. vs. 152332 build-i386-xsm6 xen-buildfail REGR. vs. 152332 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-rtds 12 guest-startfail pass in 153328 test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail pass in 153328 Tests which did not succeed, but are not blocking: test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-examine 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd11-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd12-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-int
Re: Golang design session follow-up
On Fri, Aug 28, 2020 at 07:05:08PM +, George Dunlap wrote: > > > > On Aug 28, 2020, at 4:57 PM, George Dunlap wrote: > > > > > > > >> On Jul 21, 2020, at 1:35 AM, Nick Rosbrook wrote: > >> > >> # Long-term home of the package > >> > >> Ian: Autogenerated stuff is becoming more annoying. > >> > >> Delete all the libxl auto-generated stuff from staging & master, and > >> have "output branch". > >> > >> The reason we have these in-tree is that otherwise you can't build *from > >> git* if you don't > >> have new enough versions of the right tools. > >> > >> Distribution: Make a repo on xenbits! > > > > So thinking about this: > > > > The first plan I had was to have a script in tools/golang/xenlight (and/or > > the Makefile), which would be handed a directory, and would then: > > > > 1. Sync static files from tools/golang/xenlight into that directory > > > > 2. Run gengotypes.py, having the resulting generated files put into that > > directory > > > > 3. Run `git diff` in the target directory; if there are any changes, then > > automatically run `git commit` to check in the changes. > > > > That way you could just set up a cron job to sync things over on a regular > > basis. > > > > Thinking about GPL considerations, however, you’d also want to include > > libxl_types.idl and idl.py. And then of course, you should also include a > > way to build the generated code from those two. > > > > At which point… would it make sense to just move the package out to its > > separate repo entirely? I.e., have actual development happen in the repo > > which ends up being cloned in the end? > > > > Obviously there are nice things about having the code in the same repo; but > > there’s also something satisfying about being a full downstream. > > > > I was actually thinking it might make sense to put the repo at > > https://gitlab.com/xen-project/go-xenlight , to try out that as a > > development model. Would that mean completely moving off of xen-devel for development? I can't think of a huge reason why we wouldn't be able to do this if we wanted. > > I’ve put a sort of draft module up at https://gitlab.com/martyros/go-xen ; > you can test it by adding the "gitlab.com/xen-project/go-xen/xenlight” > package, but adding the following line to the go.mod of the test program: I have a couple of patches I was going to send out on xen-devel today. I could PR them to this repo instead (or in addition) if you want to try out the gitlab workflow. -NR
Re: [PATCH v3 1/8] x86: fix compat header generation
On 23.07.2020 17:48, Jan Beulich wrote: > --- a/xen/tools/compat-build-header.py > +++ b/xen/tools/compat-build-header.py > @@ -3,7 +3,7 @@ > import re,sys > > pats = [ > - [ r"__InClUdE__(.*)", r"#include\1\n#pragma pack(4)" ], > + [ r"__InClUdE__(.*)", r"#include\1" ], > [ r"__IfDeF__ (XEN_HAVE.*)", r"#ifdef \1" ], > [ r"__ElSe__", r"#else" ], > [ r"__EnDif__", r"#endif" ], > @@ -11,9 +11,11 @@ pats = [ > [ r"__UnDeF__", r"#undef" ], > [ r"\"xen-compat.h\"", r"" ], > [ r"(struct|union|enum)\s+(xen_?)?(\w)", r"\1 compat_\3" ], > - [ r"@KeeP@", r"" ], > + [ r"typedef(.*)@KeeP@(xen_?)?([\w]+)([^\w])", > + r"typedef\1\2\3 __attribute__((__aligned__(__alignof(\1compat_\3\4" ], I've noticed only very recently that this (but not ... > [ r"_t([^\w]|$)", r"_compat_t\1" ], > - [ r"(8|16|32|64)_compat_t([^\w]|$)", r"\1_t\2" ], > + [ r"int(8|16|32|64_aligned)_compat_t([^\w]|$)", r"int\1_t\2" ], > + [ r"(\su?int64(_compat)?)_T([^\w]|$)", r"\1_t\3" ], ... this) trips an apparent bug in Python up to at least 3.4.6: "unmatched group". It's been working fine for me with 3.7. I'm not going to rule out I've screwed up the regex, but I can't see in which way. Obviously I can't commit this knowing of this issue. I'd be glad if people with better Python knowledge than mine could suggest how to fix the expression or work around the issue. Thanks much, Jan
[ovmf test] 153375: regressions - FAIL
flight 153375 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153375/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm 6 xen-buildfail REGR. vs. 152863
build-amd64 6 xen-buildfail REGR. vs. 152863
build-i3866 xen-buildfail REGR. vs. 152863
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 1 build-check(1) blocked n/a
build-i386-libvirt1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
version targeted for testing:
ovmf 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
baseline version:
ovmf 63d92674d240ab4ecab94f98e1e198842bb7de00
Last test of basis 152863 2020-08-26 16:09:47 Z4 days
Failing since152915 2020-08-27 18:09:42 Z3 days 84 attempts
Testing same since 153135 2020-08-30 02:28:59 Z1 days 28 attempts
People who touched revisions under test:
Laszlo Ersek
Paul
Paul G
jobs:
build-amd64-xsm fail
build-i386-xsm fail
build-amd64 fail
build-i386 fail
build-amd64-libvirt blocked
build-i386-libvirt blocked
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
test-amd64-i386-xl-qemuu-ovmf-amd64 blocked
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 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
Author: Paul
Date: Fri Aug 28 04:40:51 2020 +0800
MdePkg: Correcting EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT definition
In Acpi10.h, EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT is defined as 0x10,
but should be 0x02 per the ACPI Specification.
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2937
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Signed-off-by: Paul G
Reviewed-by: Liming Gao
commit cbccf995920a28071f5403b847f29ebf8b732fa9
Author: Laszlo Ersek
Date: Thu Aug 27 00:21:29 2020 +0200
OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just after SMI broadcast
The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick
succession -- it means a series of "device_add" QEMU monitor commands,
back-to-back.
If a "device_add" occurs *just after* ACPI raises the broadcast SMI, then:
- the CPU_FOREACH() loop in QEMU's ich9_apm_ctrl_changed() cannot make the
SMI pending for the new CPU -- at that time, the new CPU doesn't even
exist yet,
- OVMF will find the new CPU however (in the CPU hotplug register block),
in QemuCpuhpCollectApicIds().
As a result, when the firmware sends an INIT-SIPI-SIPI to the new CPU in
SmbaseRelocate(), expecting it to boot into SMM (due to the pending SMI),
the new CPU instead boots straight into the post-RSM (normal mode) "pen",
skipping its initial SMI handler.
The CPU halts nicely in the pen, but its SMBASE is never relocated, and
the SMRAM message exchange with the BSP falls apart -- the BSP gets stuck
in the following loop:
//
// Wait until the hot-added CPU is just about to execute RSM.
//
while (Context->AboutToLeaveSmm == 0) {
CpuPause ();
}
because the new CPU's initial SMI handler never sets the flag to nonzero.
Fix this by sending a directed SMI to the new CPU just before sending it
the INIT-SIPI-SIPI. The various scenarios are documented in the code --
the cases affected by the patch are documented under point (2).
Note that this is not considered a security patch, as for
Re: [PATCH] x86/pv: Fix multiple bugs with SEGBASE_GS_USER_SEL
On 31.08.2020 13:18, Andrew Cooper wrote:
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -1059,16 +1059,52 @@ long do_set_segment_base(unsigned int which, unsigned
> long base)
> break;
>
> case SEGBASE_GS_USER_SEL:
> -__asm__ __volatile__ (
> -" swapgs \n"
> -"1: movl %k0,%%gs \n"
> -""safe_swapgs"\n"
> -".section .fixup,\"ax\" \n"
> -"2: xorl %k0,%k0\n"
> -" jmp 1b \n"
> -".previous\n"
> -_ASM_EXTABLE(1b, 2b)
> -: "+r" (base) );
> +/*
> + * We wish to update the user %gs from the GDT/LDT. Currently, the
> + * guest kernel's GS_BASE is in context.
> + */
> +asm volatile ( "swapgs" );
> +
> +if ( base <= 3 )
Either !(base & 0xfffc) or you want to truncate the input to
uint16_t first. The upper 48 bits have always been ignored. With
this addressed one way or another
Reviewed-by: Jan Beulich
Yet two more minor comments:
> +{
> +/* Work around NUL segment behaviour on AMD hardware. */
> +if ( boot_cpu_data.x86_vendor &
> + (X86_VENDOR_AMD | X86_VENDOR_HYGON) )
> +asm volatile ( "mov %[sel], %%gs"
> + :: [sel] "rm" (FLAT_USER_DS32) );
> +}
> +else
> +/* Fix up RPL. */
> +base |= 3;
For a fair part of this block you could save a level of indentation
by inverting the initial condition and using "else if" later on.
> +/*
> + * Load the chosen selector, with fault handling.
> + *
> + * Errors ought to fail the hypercall, but that was never built in
> + * originally, and Linux will BUG() if this call fails.
> + *
> + * NUL the selector in the case of an error. This too needs to deal
> + * with the AMD NUL segment behaviour, but it is already a slowpath
> in
> + * #GP context so perform the flat load unconditionally to avoid
> + * complicated logic.
> + *
> + * Anyone wanting to check for errors from this hypercall should
> + * re-read %gs and compare against the input 'base' selector.
> + */
> +asm volatile ( "1: mov %k[sel], %%gs\n\t"
> + ".section .fixup, \"ax\", @progbits\n\t"
> + "2: mov %k[flat], %%gs\n\t"
> + " xor %k[sel], %k[sel]\n\t"
> + " jmp 1b\n\t"
> + ".previous\n\t"
> + _ASM_EXTABLE(1b, 2b)
> + : [sel] "+r" (base)
> + : [flat] "rm" (FLAT_USER_DS32) );
"m" is pointless to specify here - the compiler won't instantiate a
memory variable when the value is an immediate. This can be observed
best when you specify _just_ "m" here.
Jan
[ovmf test] 153368: regressions - FAIL
flight 153368 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153368/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm 6 xen-buildfail REGR. vs. 152863
build-amd64 6 xen-buildfail REGR. vs. 152863
build-i3866 xen-buildfail REGR. vs. 152863
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 1 build-check(1) blocked n/a
build-i386-libvirt1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
version targeted for testing:
ovmf 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
baseline version:
ovmf 63d92674d240ab4ecab94f98e1e198842bb7de00
Last test of basis 152863 2020-08-26 16:09:47 Z4 days
Failing since152915 2020-08-27 18:09:42 Z3 days 83 attempts
Testing same since 153135 2020-08-30 02:28:59 Z1 days 27 attempts
People who touched revisions under test:
Laszlo Ersek
Paul
Paul G
jobs:
build-amd64-xsm fail
build-i386-xsm fail
build-amd64 fail
build-i386 fail
build-amd64-libvirt blocked
build-i386-libvirt blocked
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
test-amd64-i386-xl-qemuu-ovmf-amd64 blocked
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 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
Author: Paul
Date: Fri Aug 28 04:40:51 2020 +0800
MdePkg: Correcting EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT definition
In Acpi10.h, EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT is defined as 0x10,
but should be 0x02 per the ACPI Specification.
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2937
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Signed-off-by: Paul G
Reviewed-by: Liming Gao
commit cbccf995920a28071f5403b847f29ebf8b732fa9
Author: Laszlo Ersek
Date: Thu Aug 27 00:21:29 2020 +0200
OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just after SMI broadcast
The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick
succession -- it means a series of "device_add" QEMU monitor commands,
back-to-back.
If a "device_add" occurs *just after* ACPI raises the broadcast SMI, then:
- the CPU_FOREACH() loop in QEMU's ich9_apm_ctrl_changed() cannot make the
SMI pending for the new CPU -- at that time, the new CPU doesn't even
exist yet,
- OVMF will find the new CPU however (in the CPU hotplug register block),
in QemuCpuhpCollectApicIds().
As a result, when the firmware sends an INIT-SIPI-SIPI to the new CPU in
SmbaseRelocate(), expecting it to boot into SMM (due to the pending SMI),
the new CPU instead boots straight into the post-RSM (normal mode) "pen",
skipping its initial SMI handler.
The CPU halts nicely in the pen, but its SMBASE is never relocated, and
the SMRAM message exchange with the BSP falls apart -- the BSP gets stuck
in the following loop:
//
// Wait until the hot-added CPU is just about to execute RSM.
//
while (Context->AboutToLeaveSmm == 0) {
CpuPause ();
}
because the new CPU's initial SMI handler never sets the flag to nonzero.
Fix this by sending a directed SMI to the new CPU just before sending it
the INIT-SIPI-SIPI. The various scenarios are documented in the code --
the cases affected by the patch are documented under point (2).
Note that this is not considered a security patch, as for
[ovmf test] 153360: regressions - FAIL
flight 153360 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153360/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm 6 xen-buildfail REGR. vs. 152863
build-amd64 6 xen-buildfail REGR. vs. 152863
build-i3866 xen-buildfail REGR. vs. 152863
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 1 build-check(1) blocked n/a
build-i386-libvirt1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
version targeted for testing:
ovmf 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
baseline version:
ovmf 63d92674d240ab4ecab94f98e1e198842bb7de00
Last test of basis 152863 2020-08-26 16:09:47 Z4 days
Failing since152915 2020-08-27 18:09:42 Z3 days 82 attempts
Testing same since 153135 2020-08-30 02:28:59 Z1 days 26 attempts
People who touched revisions under test:
Laszlo Ersek
Paul
Paul G
jobs:
build-amd64-xsm fail
build-i386-xsm fail
build-amd64 fail
build-i386 fail
build-amd64-libvirt blocked
build-i386-libvirt blocked
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
test-amd64-i386-xl-qemuu-ovmf-amd64 blocked
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 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
Author: Paul
Date: Fri Aug 28 04:40:51 2020 +0800
MdePkg: Correcting EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT definition
In Acpi10.h, EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT is defined as 0x10,
but should be 0x02 per the ACPI Specification.
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2937
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Signed-off-by: Paul G
Reviewed-by: Liming Gao
commit cbccf995920a28071f5403b847f29ebf8b732fa9
Author: Laszlo Ersek
Date: Thu Aug 27 00:21:29 2020 +0200
OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just after SMI broadcast
The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick
succession -- it means a series of "device_add" QEMU monitor commands,
back-to-back.
If a "device_add" occurs *just after* ACPI raises the broadcast SMI, then:
- the CPU_FOREACH() loop in QEMU's ich9_apm_ctrl_changed() cannot make the
SMI pending for the new CPU -- at that time, the new CPU doesn't even
exist yet,
- OVMF will find the new CPU however (in the CPU hotplug register block),
in QemuCpuhpCollectApicIds().
As a result, when the firmware sends an INIT-SIPI-SIPI to the new CPU in
SmbaseRelocate(), expecting it to boot into SMM (due to the pending SMI),
the new CPU instead boots straight into the post-RSM (normal mode) "pen",
skipping its initial SMI handler.
The CPU halts nicely in the pen, but its SMBASE is never relocated, and
the SMRAM message exchange with the BSP falls apart -- the BSP gets stuck
in the following loop:
//
// Wait until the hot-added CPU is just about to execute RSM.
//
while (Context->AboutToLeaveSmm == 0) {
CpuPause ();
}
because the new CPU's initial SMI handler never sets the flag to nonzero.
Fix this by sending a directed SMI to the new CPU just before sending it
the INIT-SIPI-SIPI. The various scenarios are documented in the code --
the cases affected by the patch are documented under point (2).
Note that this is not considered a security patch, as for
Re: [PATCH v1 2/5] kernel/resource: merge_system_ram_resources() to merge resources after hotplug
> Some add_memory*() users add memory in small, contiguous memory blocks.
> Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
>
> This can quickly result in a lot of memory resources, whereby the actual
> resource boundaries are not of interest (e.g., it might be relevant for
> DIMMs, exposed via /proc/iomem to user space). We really want to merge
> added resources in this scenario where possible.
>
> Let's provide an interface to trigger merging of applicable child
> resources. It will be, for example, used by virtio-mem to trigger
> merging of system ram resources it added to its resource container, but
> also by XEN and Hyper-V to trigger merging of system ram resources in
> iomem_resource.
>
> Note: We really want to merge after the whole operation succeeded, not
> directly when adding a resource to the resource tree (it would break
> add_memory_resource() and require splitting resources again when the
> operation failed - e.g., due to -ENOMEM).
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Dan Williams
> Cc: Jason Gunthorpe
> Cc: Kees Cook
> Cc: Ard Biesheuvel
> Cc: Thomas Gleixner
> Cc: "K. Y. Srinivasan"
> Cc: Haiyang Zhang
> Cc: Stephen Hemminger
> Cc: Wei Liu
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Stefano Stabellini
> Cc: Roger Pau Monné
> Cc: Julien Grall
> Cc: Pankaj Gupta
> Cc: Baoquan He
> Cc: Wei Yang
> Signed-off-by: David Hildenbrand
> ---
> include/linux/ioport.h | 3 +++
> kernel/resource.c | 52 ++
> 2 files changed, 55 insertions(+)
>
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index 52a91f5fa1a36..3bb0020cd6ddc 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -251,6 +251,9 @@ extern void __release_region(struct resource *,
> resource_size_t,
> extern void release_mem_region_adjustable(struct resource *, resource_size_t,
> resource_size_t);
> #endif
> +#ifdef CONFIG_MEMORY_HOTPLUG
> +extern void merge_system_ram_resources(struct resource *res);
> +#endif
>
> /* Wrappers for managed devices */
> struct device;
> diff --git a/kernel/resource.c b/kernel/resource.c
> index 1dcef5d53d76e..b4e0963edadd2 100644
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -1360,6 +1360,58 @@ void release_mem_region_adjustable(struct resource
> *parent,
> }
> #endif /* CONFIG_MEMORY_HOTREMOVE */
>
> +#ifdef CONFIG_MEMORY_HOTPLUG
> +static bool system_ram_resources_mergeable(struct resource *r1,
> + struct resource *r2)
> +{
> + return r1->flags == r2->flags && r1->end + 1 == r2->start &&
> + r1->name == r2->name && r1->desc == r2->desc &&
> + !r1->child && !r2->child;
> +}
> +
> +/*
> + * merge_system_ram_resources - try to merge contiguous system ram resources
> + * @parent: parent resource descriptor
> + *
> + * This interface is intended for memory hotplug, whereby lots of contiguous
> + * system ram resources are added (e.g., via add_memory*()) by a driver, and
> + * the actual resource boundaries are not of interest (e.g., it might be
> + * relevant for DIMMs). Only immediate child resources that are busy and
> + * don't have any children are considered. All applicable child resources
> + * must be immutable during the request.
> + *
> + * Note:
> + * - The caller has to make sure that no pointers to resources that might
> + * get merged are held anymore. Callers should only trigger merging of
> child
> + * resources when they are the only one adding system ram resources to the
> + * parent (besides during boot).
> + * - release_mem_region_adjustable() will split on demand on memory hotunplug
> + */
> +void merge_system_ram_resources(struct resource *parent)
> +{
> + const unsigned long flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> + struct resource *cur, *next;
> +
> + write_lock(&resource_lock);
> +
> + cur = parent->child;
> + while (cur && cur->sibling) {
> + next = cur->sibling;
> + if ((cur->flags & flags) == flags &&
Maybe this can be changed to:
!(cur->flags & ~flags)
> + system_ram_resources_mergeable(cur, next)) {
> + cur->end = next->end;
> + cur->sibling = next->sibling;
> + free_resource(next);
> + next = cur->sibling;
> + }
> + cur = next;
> + }
> +
> + write_unlock(&resource_lock);
> +}
> +EXPORT_SYMBOL(merge_system_ram_resources);
> +#endif /* CONFIG_MEMORY_HOTPLUG */
> +
> /*
> * Managed region resource
> */
> --
> 2.26.2
>
[xen-unstable test] 153321: regressions - FAIL
flight 153321 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/153321/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 152877 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 152877 Tests which are failing intermittently (not blocking): test-amd64-i386-xl 21 guest-start.2fail in 153280 pass in 153321 test-armhf-armhf-xl-rtds 12 guest-startfail pass in 153280 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds13 migrate-support-check fail in 153280 never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 153280 never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 152877 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 152877 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 152877 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 152877 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 152877 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 152877 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 152877 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 152877 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 152877 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass version targeted for testing: xen d400dc5729e4e132d61c2e7df57d81aaed762044 baseline version: xen 7a8d8bde9820387c3e168182b99fd9761c223fff Last test of basis 152877 2020-08-27 01:51:40
[qemu-mainline test] 153336: regressions - FAIL
flight 153336 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/153336/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3866 xen-buildfail REGR. vs. 152631 build-amd64-xsm 6 xen-buildfail REGR. vs. 152631 build-i386-xsm6 xen-buildfail REGR. vs. 152631 build-amd64 6 xen-buildfail REGR. vs. 152631 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 152631 test-armhf-armhf-xl-vhd 10 debian-di-installfail REGR. vs. 152631 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 152631 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 152631 Tests which are failing intermittently (not blocking): test-arm64-arm64-xl-seattle 7 xen-boot fail in 153311 pass in 153336 test-armhf-armhf-xl-rtds 15 guest-stop fail pass in 153311 Tests which did not succeed, but are not blocking: test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd11-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd12-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-de
[ovmf test] 153353: regressions - FAIL
flight 153353 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153353/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm 6 xen-buildfail REGR. vs. 152863
build-amd64 6 xen-buildfail REGR. vs. 152863
build-i3866 xen-buildfail REGR. vs. 152863
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 1 build-check(1) blocked n/a
build-i386-libvirt1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
version targeted for testing:
ovmf 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
baseline version:
ovmf 63d92674d240ab4ecab94f98e1e198842bb7de00
Last test of basis 152863 2020-08-26 16:09:47 Z4 days
Failing since152915 2020-08-27 18:09:42 Z3 days 81 attempts
Testing same since 153135 2020-08-30 02:28:59 Z1 days 25 attempts
People who touched revisions under test:
Laszlo Ersek
Paul
Paul G
jobs:
build-amd64-xsm fail
build-i386-xsm fail
build-amd64 fail
build-i386 fail
build-amd64-libvirt blocked
build-i386-libvirt blocked
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
test-amd64-i386-xl-qemuu-ovmf-amd64 blocked
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 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
Author: Paul
Date: Fri Aug 28 04:40:51 2020 +0800
MdePkg: Correcting EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT definition
In Acpi10.h, EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT is defined as 0x10,
but should be 0x02 per the ACPI Specification.
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2937
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Signed-off-by: Paul G
Reviewed-by: Liming Gao
commit cbccf995920a28071f5403b847f29ebf8b732fa9
Author: Laszlo Ersek
Date: Thu Aug 27 00:21:29 2020 +0200
OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just after SMI broadcast
The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick
succession -- it means a series of "device_add" QEMU monitor commands,
back-to-back.
If a "device_add" occurs *just after* ACPI raises the broadcast SMI, then:
- the CPU_FOREACH() loop in QEMU's ich9_apm_ctrl_changed() cannot make the
SMI pending for the new CPU -- at that time, the new CPU doesn't even
exist yet,
- OVMF will find the new CPU however (in the CPU hotplug register block),
in QemuCpuhpCollectApicIds().
As a result, when the firmware sends an INIT-SIPI-SIPI to the new CPU in
SmbaseRelocate(), expecting it to boot into SMM (due to the pending SMI),
the new CPU instead boots straight into the post-RSM (normal mode) "pen",
skipping its initial SMI handler.
The CPU halts nicely in the pen, but its SMBASE is never relocated, and
the SMRAM message exchange with the BSP falls apart -- the BSP gets stuck
in the following loop:
//
// Wait until the hot-added CPU is just about to execute RSM.
//
while (Context->AboutToLeaveSmm == 0) {
CpuPause ();
}
because the new CPU's initial SMI handler never sets the flag to nonzero.
Fix this by sending a directed SMI to the new CPU just before sending it
the INIT-SIPI-SIPI. The various scenarios are documented in the code --
the cases affected by the patch are documented under point (2).
Note that this is not considered a security patch, as for
[linux-linus test] 153328: regressions - FAIL
flight 153328 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/153328/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3866 xen-buildfail REGR. vs. 152332 build-amd64-xsm 6 xen-buildfail REGR. vs. 152332 build-amd64 6 xen-buildfail REGR. vs. 152332 build-i386-xsm6 xen-buildfail REGR. vs. 152332 Tests which did not succeed, but are not blocking: test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-examine 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd11-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd12-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64
Ping: [PATCH v3 5/8] evtchn: add compat struct checking for newer sub-ops
On 23.07.2020 17:50, Jan Beulich wrote: > Various additions to the interface did not get mirrored into the compat > handling machinery. Luckily all additions were done in ways not making > any form of translation necessary. > > Signed-off-by: Jan Beulich > --- > v3: New. Anyone? For the rest of this series, I'm going to put it in with Roger's R-b-s, as there hasn't been other feedback in over a month. As the one here is sufficiently simple and of little risk, I think I'll also time out waiting for an ack or R-b by the end of the week. Jan > --- a/xen/common/compat/xlat.c > +++ b/xen/common/compat/xlat.c > @@ -54,6 +54,22 @@ CHECK_evtchn_op; > #undef xen_evtchn_status > #undef xen_evtchn_unmask > > +#define xen_evtchn_expand_array evtchn_expand_array > +CHECK_evtchn_expand_array; > +#undef xen_evtchn_expand_array > + > +#define xen_evtchn_init_control evtchn_init_control > +CHECK_evtchn_init_control; > +#undef xen_evtchn_init_control > + > +#define xen_evtchn_reset evtchn_reset > +CHECK_evtchn_reset; > +#undef xen_evtchn_reset > + > +#define xen_evtchn_set_priority evtchn_set_priority > +CHECK_evtchn_set_priority; > +#undef xen_evtchn_set_priority > + > #define xen_mmu_update mmu_update > CHECK_mmu_update; > #undef xen_mmu_update > --- a/xen/include/xlat.lst > +++ b/xen/include/xlat.lst > @@ -66,8 +66,12 @@ > ?evtchn_bind_vcpuevent_channel.h > ?evtchn_bind_virqevent_channel.h > ?evtchn_closeevent_channel.h > +?evtchn_expand_array event_channel.h > +?evtchn_init_control event_channel.h > ?evtchn_op event_channel.h > +?evtchn_resetevent_channel.h > ?evtchn_send event_channel.h > +?evtchn_set_priority event_channel.h > ?evtchn_status event_channel.h > ?evtchn_unmask event_channel.h > ?gnttab_cache_flush grant_table.h >
[ovmf test] 153349: regressions - FAIL
flight 153349 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/153349/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 152863
build-amd64-xsm 6 xen-buildfail REGR. vs. 152863
build-amd64 6 xen-buildfail REGR. vs. 152863
build-i3866 xen-buildfail REGR. vs. 152863
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 1 build-check(1) blocked n/a
build-i386-libvirt1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
version targeted for testing:
ovmf 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
baseline version:
ovmf 63d92674d240ab4ecab94f98e1e198842bb7de00
Last test of basis 152863 2020-08-26 16:09:47 Z4 days
Failing since152915 2020-08-27 18:09:42 Z3 days 80 attempts
Testing same since 153135 2020-08-30 02:28:59 Z1 days 24 attempts
People who touched revisions under test:
Laszlo Ersek
Paul
Paul G
jobs:
build-amd64-xsm fail
build-i386-xsm fail
build-amd64 fail
build-i386 fail
build-amd64-libvirt blocked
build-i386-libvirt blocked
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
test-amd64-i386-xl-qemuu-ovmf-amd64 blocked
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 5ffcbc46908a2037ae3260d3cfcc103e4a6a48c0
Author: Paul
Date: Fri Aug 28 04:40:51 2020 +0800
MdePkg: Correcting EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT definition
In Acpi10.h, EFI_ACPI_DMA_TRANSFER_TYPE_16_BIT is defined as 0x10,
but should be 0x02 per the ACPI Specification.
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2937
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Signed-off-by: Paul G
Reviewed-by: Liming Gao
commit cbccf995920a28071f5403b847f29ebf8b732fa9
Author: Laszlo Ersek
Date: Thu Aug 27 00:21:29 2020 +0200
OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just after SMI broadcast
The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick
succession -- it means a series of "device_add" QEMU monitor commands,
back-to-back.
If a "device_add" occurs *just after* ACPI raises the broadcast SMI, then:
- the CPU_FOREACH() loop in QEMU's ich9_apm_ctrl_changed() cannot make the
SMI pending for the new CPU -- at that time, the new CPU doesn't even
exist yet,
- OVMF will find the new CPU however (in the CPU hotplug register block),
in QemuCpuhpCollectApicIds().
As a result, when the firmware sends an INIT-SIPI-SIPI to the new CPU in
SmbaseRelocate(), expecting it to boot into SMM (due to the pending SMI),
the new CPU instead boots straight into the post-RSM (normal mode) "pen",
skipping its initial SMI handler.
The CPU halts nicely in the pen, but its SMBASE is never relocated, and
the SMRAM message exchange with the BSP falls apart -- the BSP gets stuck
in the following loop:
//
// Wait until the hot-added CPU is just about to execute RSM.
//
while (Context->AboutToLeaveSmm == 0) {
CpuPause ();
}
because the new CPU's initial SMI handler never sets the flag to nonzero.
Fix this by sending a directed SMI to the new CPU just before sending it
the INIT-SIPI-SIPI. The various scenarios are documented in the code --
the cases affected by the patch are documented under point (2).
Note that this is not considered a security patch, as for
Re: [patch V2 00/46] x86, PCI, XEN, genirq ...: Prepare for device MSI
Hi Thomas, On 2020/8/31 15:10, Thomas Gleixner wrote: On Mon, Aug 31 2020 at 08:51, Lu Baolu wrote: On 8/26/20 7:16 PM, Thomas Gleixner wrote: This is the second version of providing a base to support device MSI (non PCI based) and on top of that support for IMS (Interrupt Message Storm) based devices in a halfways architecture independent way. After applying this patch series, the dmar_alloc_hwirq() helper doesn't work anymore during boot. This causes the IOMMU driver to fail to register the DMA fault handler and abort the IOMMU probe processing. Is this a known issue? See replies to patch 15/46 or pull the git tree. It has the issue fixed. Ah! Yes. Sorry for the noise. Beset regards, baolu
[libvirt test] 153338: regressions - FAIL
flight 153338 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/153338/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-i3866 xen-buildfail REGR. vs. 151777 build-i386-xsm6 xen-buildfail REGR. vs. 151777 build-amd64-xsm 6 xen-buildfail REGR. vs. 151777 build-amd64 6 xen-buildfail REGR. vs. 151777 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-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-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a version targeted for testing: libvirt b2672b33dc54371b2ed0d585c4ab4f1badc86536 baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z 52 days Failing since151818 2020-07-11 04:18:52 Z 51 days 47 attempts Testing same since 153338 2020-08-31 04:19:05 Z0 days1 attempts People who touched revisions under test: Andrea Bolognani Balázs Meskó Bastien Orivel Bihong Yu Binfeng Wu Boris Fiuczynski Christian Ehrhardt Côme Borsoi Daniel Henrique Barboza Daniel P. Berrange Daniel P. Berrangé Erik Skultety Fangge Jin Fedora Weblate Translation Han Han Hao Wang Jamie Strandboge Jamie Strandboge Jean-Baptiste Holcroft Jianan Gao Jim Fehlig Jin Yan Jiri Denemark Ján Tomko Kashyap Chamarthy Kevin Locke Laine Stump Liao Pingfang Martin Kletzander Michal Privoznik Nikolay Shirokovskiy Paulo de Rezende Pinatti Pavel Hrdina Peter Krempa Pino Toscano Pino Toscano Piotr Drąg Prathamesh Chavan Roman Bogorodskiy Ryan Schmidt Sam Hartman Scott Shambarger Stefan Bader Stefan Berger Szymon Scholz Tomáš Golembiovský Wang Xin Weblate Yang Hang Yi Wang Yuri Chornoivan Zheng Chuan jobs: build-amd64-xsm fail build-arm64-xsm pass build-i386-xsm fail build-amd64 fail build-arm64 pass build-armhf pass build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt blocked build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i38
Re: [EXTERNAL] [PATCH v7 8/9] x86/time: add a domain context record for tsc_info...
On 28.08.2020 18:36, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 28 August 2020 16:53
>> To: p...@xen.org
>> Cc: xen-devel@lists.xenproject.org; 'Ian Jackson'
>> ; 'Wei Liu' ;
>> 'Andrew Cooper' ; 'George Dunlap'
>> ; 'Julien
>> Grall' ; 'Stefano Stabellini' ;
>> 'Roger Pau Monné'
>>
>> Subject: Re: [EXTERNAL] [PATCH v7 8/9] x86/time: add a domain context record
>> for tsc_info...
>>
>> On 28.08.2020 13:08, Paul Durrant wrote:
-Original Message-
From: Jan Beulich
Sent: 26 August 2020 15:03
To: Paul Durrant
Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
Ian Jackson
; Wei Liu ; Andrew Cooper
;
>> George
Dunlap ; Julien Grall ; Stefano
Stabellini
; Roger Pau Monné
Subject: RE: [EXTERNAL] [PATCH v7 8/9] x86/time: add a domain context
record for tsc_info...
CAUTION: This email originated from outside of the organization. Do not
click links or open
attachments unless you can confirm the sender and know the content is safe.
On 18.08.2020 12:30, Paul Durrant wrote:
> --- a/xen/include/public/save.h
> +++ b/xen/include/public/save.h
> @@ -93,7 +93,18 @@ struct domain_shared_info_context {
>
> DECLARE_DOMAIN_SAVE_TYPE(SHARED_INFO, 2, struct
> domain_shared_info_context);
>
> -#define DOMAIN_SAVE_CODE_MAX 2
> +#if defined(__i386__) || defined(__x86_64__)
> +struct domain_tsc_info_context {
> +uint32_t mode;
> +uint32_t incarnation;
> +uint64_t elapsed_nsec;
> +uint32_t khz;
> +};
sizeof() for this struct varies between 32-bit and 64-bit - is
this not a problem? (alignof() varies too, but there I think
it's indeed not a problem, albeit it could still be taken care
of by using uint64_aligned_t, alongside the addition of an
explicit padding field).
>>>
>>> I don't think it should matter because domain context records have
>>> implicit padding to align up to the next 64-bit boundary,
>>
>> Could you remind me where this is written down and enforced?
>>
>
> With the series fully applied, see xen/include/public/save.h
> line 62-68 for the comment and then see domain_save_end() in
> xen/common/save.c for where the padding is applied.
Ah, yes, this helped find the places in the patches. Therefore with
the stray blank line addition removed from tools/misc/xen-domctx.c
Reviewed-by: Jan Beulich
Jan
Re: [patch V2 00/46] x86, PCI, XEN, genirq ...: Prepare for device MSI
On Mon, Aug 31 2020 at 08:51, Lu Baolu wrote: > On 8/26/20 7:16 PM, Thomas Gleixner wrote: >> This is the second version of providing a base to support device MSI (non >> PCI based) and on top of that support for IMS (Interrupt Message Storm) >> based devices in a halfways architecture independent way. > > After applying this patch series, the dmar_alloc_hwirq() helper doesn't > work anymore during boot. This causes the IOMMU driver to fail to > register the DMA fault handler and abort the IOMMU probe processing. > Is this a known issue? See replies to patch 15/46 or pull the git tree. It has the issue fixed. Thanks, tglx
Re: [PATCH] x86/intel: Expose MSR_ARCH_CAPS to dom0
On 28.08.2020 18:38, Andrew Cooper wrote: > On 28/08/2020 17:17, Jan Beulich wrote: >> On 28.08.2020 18:09, Andrew Cooper wrote: >>> On 28/08/2020 16:42, Jan Beulich wrote: On 28.08.2020 12:23, Andrew Cooper wrote: > On 28/08/2020 09:41, Jan Beulich wrote: >> On 27.08.2020 21:37, Andrew Cooper wrote: >>> The overhead of (the lack of) MDS_NO alone has been measured at 30% on >>> some >>> workloads. While we're not in a position yet to offer MSR_ARCH_CAPS >>> generally >>> to guests, dom0 doesn't migrate, so we can pass a subset of hardware >>> values >>> straight through. >>> >>> This will cause PVH dom0's not to use KPTI by default, and all dom0's >>> not to >>> use VERW flushing by default, >> To avoid VERW, shouldn't you also expose SKIP_L1DFL? > SKIP_L1DFL is a software-only bit, specifically for nested virt. > > It is for Xen to tell an L1 hypervisor "you don't need to flush on > vmentry because I'm taking care of it". Or for a hypervisor underneath us to tell us, which we could then hand on to Dom0? >>> For dom0 to do what with? >>> >>> PV guests can't use the VMLAUNCH/VMRESUME instruction at all, and it is >>> not currently possible to configure nested virt for a PVH dom0 to use. >> Aren't they also using this on the exit-to-user-mode path, like we >> do on exit-to-PV? And in certain cases when idle? > > MSR_FLUSH_CMD is used used for VMEntry. This flushes the L1D cache, and > was to combat L1TF. Native systems don't flush the L1D at all, and > invert PTEs instead as a *far* lower overhead mitigation. > > Then MDS came along. VERW is used to flush the uarch buffers. This > needs doing in all return-to-guest contexts. > > As VMEntry needs both, MSR_FLUSH_CMD's behaviour was extended to cover > both the L1D cache and uarch buffers, so software didn't have to arrange > for both. > > Therefore, the overall mitigations are VERW on exit-to-PV, and > MSR_FLUSH_CMD on exit-to-HVM. > > > There is no current need for native setups to use MSR_FLUSH_CMD. The > only reason we expose the MSR to HVM guests is for nested-virt. But the question was about the use of VERW on exit-to-user paths in a PV kernel, which I apparently wrongly understood SKIP_L1DFL also indicates to be unnecessary. I'm sorry for the confusion. So Reviewed-by: Jan Beulich Jan
