flight 138719 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138719/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx broken
build-amd64-prev 6 xen-bu
flight 138729 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138729/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xen-freebsd 7 xen-build-freebsdfail REGR. vs. 138540
version targeted
On 03.07.2019 21:47, Andrew Cooper wrote:
> On 03/07/2019 11:34, Jan Beulich wrote:
>> On 03.07.2019 12:21, Andrew Cooper wrote:
>>> I'm still opposed to this. The introduction of ? does more harm than
>>> good IMO, because it simply can't be trusted.
>>>
>>> Stack traces are not guaranteed-accura
On 03.07.2019 17:22, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 03 July 2019 12:36
>> To: xen-devel@lists.xenproject.org
>> Cc: George Dunlap ; Paul Durrant
>> ; Andrew Cooper
>> ; Wei Liu ; Roger Pau Monne
>>
>> Subject: [PATCH v2] x86/HVM: p2m_ram_ro is in
On 03.07.2019 17:39, Andrew Cooper wrote:
> On 17/05/2019 11:44, Jan Beulich wrote:
>> The flag being set may prevent affinity changes, as these often imply
>> assignment of a new vector. When there's no possible destination left
>> for the IRQ, the clearing of the flag needs to happen right from
>
> -Original Message-
> From: Jan Beulich
> Sent: 04 July 2019 10:19
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Roger Pau
> Monne ; Wei Liu
> Subject: Re: [PATCH v2] x86/HVM: p2m_ram_ro is incompatible with device
> pass-through
>
> On 03
On 03.07.2019 19:58, Andrew Cooper wrote:
> On 17/05/2019 11:46, Jan Beulich wrote:
>> @@ -2334,9 +2339,10 @@ static void dump_irqs(unsigned char key)
>>
>> spin_lock_irqsave(&desc->lock, flags);
>>
>> -printk(" IRQ:%4d aff:%*pb vec:%02x %-15s status=%03x ",
>> -
On 03.07.2019 20:23, Andrew Cooper wrote:
> On 17/05/2019 11:47, Jan Beulich wrote:
>> All of __{assign,bind,clear}_irq_vector() manipulate struct irq_desc
>> fields, and hence ought to be called with the descriptor lock held in
>> addition to vector_lock. This is currently the case for only
>> set
On 03.07.2019 20:41, Andrew Cooper wrote:
> On 17/05/2019 11:51, Jan Beulich wrote:
>> --- a/xen/arch/x86/irq.c
>> +++ b/xen/arch/x86/irq.c
>> @@ -137,6 +137,13 @@ static void trace_irq_mask(uint32_t even
>> trace_var(event, 1, sizeof(d), &d);
>> }
>>
>> +static inline void trace_irq_mas
On 03.07.2019 20:44, Andrew Cooper wrote:
> On 20/05/2019 15:22, Roger Pau Monné wrote:
>> On Fri, May 17, 2019 at 04:52:54AM -0600, Jan Beulich wrote:
>>> Use scratch_cpumask where possible, to avoid creating these possibly
>>> large stack objects. We can't use it in _assign_irq_vector() and
>>> s
On 04.07.2019 11:35, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 04 July 2019 10:19
>> To: Paul Durrant ; xen-devel@lists.xenproject.org
>> Cc: Andrew Cooper ; George Dunlap
>> ; Roger Pau
>> Monne ; Wei Liu
>> Subject: Re: [PATCH v2] x86/HVM: p2m_ram_ro is in
> -Original Message-
> From: Jan Beulich
> Sent: 04 July 2019 11:09
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Roger Pau
> Monne ; Wei Liu
> Subject: Re: [Xen-devel] [PATCH v2] x86/HVM: p2m_ram_ro is incompatible with
> device pass-throug
All,
I am pleased to announce the release of Xen 4.10.4. This is available
immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.10
(tag RELEASE-4.10.4) or from the XenProject download page
https://xenproject.org/downloads/xen-project-archive
flight 138723 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138723/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx broken
build-amd64-prev 6 xen-bu
On 03/07/2019 13:18, Jan Beulich wrote:
> There are currently three more or less different checks:
> - _get_page_type() adjusts the IOMMU mappings according to the new type
>alone,
> - arch_iommu_populate_page_table() wants just the type to be
>PGT_writable_page,
> - iommu_hwdom_init() addi
On 01/07/2019 12:16, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 07/02/2019 11:42, Jan Beulich wrote:
> There are a few array accesses here the indexes of which are (at least
> indirectly) driven by the guest. Use array_access_nospec() to bound
> such accesses. In the {,_}decode_gpr() cases replace existing guarding
> constructs.
>
> To deal with an otherwise
On 31/01/2019 14:26, Jan Beulich wrote:
> Array indexes used in the MMIO read/write emulation functions are
> derived from guest controlled values. Restrict their ranges to limit the
> side effects of speculative execution.
>
> Note that the index into .msi_ad[] may also be out of bounds, by exactl
On 31/01/2019 14:26, Jan Beulich wrote:
> Array indexes used in the I/O port read/write emulation functions are
> derived from guest controlled values. Where this is not already done,
> restrict their ranges to limit the side effects of speculative execution.
>
> Signed-off-by: Jan Beulich
Review
On 04.07.2019 15:10, Andrew Cooper wrote:
> On 03/07/2019 13:18, Jan Beulich wrote:
>> There are currently three more or less different checks:
>> - _get_page_type() adjusts the IOMMU mappings according to the new type
>> alone,
>> - arch_iommu_populate_page_table() wants just the type to be
>>
On 31/01/2019 14:27, Jan Beulich wrote:
> Array indexes used in the MMIO and MSR read/write emulation functions
> are derived from guest controlled values. Restrict their ranges to limit
> the side effects of speculative execution.
>
> Remove the unused vlapic_lvt_{vector,dm}() instead of adjusting
On 01/07/2019 12:17, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
> @@ -662,8 +662,6 @@ static inline unsigned long *decode_gpr(
> BUILD_BUG_ON(ARRAY_SIZE(cpu_user_regs_gpr_offsets) &
>(ARRAY_SIZE(cpu_user
On 01/07/2019 12:18, Jan Beulich wrote:
> There was an encoding mistake in the EVEX Disp8 test code, which was
> benign (due to %rdx getting set to zero) to all non-vSIB tests as it
> mistakenly encoded (%rdx,%rdx) instead of (%rdx,%riz). In
> the vSIB case this meant (%rdx,%zmm2) instead of the in
On 04.07.2019 15:44, Andrew Cooper wrote:
> On 31/01/2019 14:27, Jan Beulich wrote:
>> Array indexes used in the MMIO and MSR read/write emulation functions
>> are derived from guest controlled values. Restrict their ranges to limit
>> the side effects of speculative execution.
>>
>> Remove the unu
On 01/07/2019 12:18, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -9100,6 +9100,133 @@ x86_emulate(
> put_stub(stub);
>
> if ( rc != X86EMUL_OKAY )
> +goto done;
> +
> +state->simd_si
On 04/07/2019 15:10, Andrew Cooper wrote:
> On 01/07/2019 12:18, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -9100,6 +9100,133 @@ x86_emulate(
>> put_stub(stub);
>>
>> if ( rc != X86EMUL_OKAY )
>> +
On 01/07/2019 12:20, Jan Beulich wrote:
> This completes support of AVX512F in the insn emulator.
>
> Note that in the test harness there's a little bit of trickery needed to
> get around the not fully consistent naming of AVX512VL gather and
> scatter compiler built-ins. To suppress expansion of t
On 04.07.2019 16:10, Andrew Cooper wrote:
> On 01/07/2019 12:18, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -9100,6 +9100,133 @@ x86_emulate(
>>put_stub(stub);
>>
>>if ( rc != X86EMUL_OKAY )
>>
On 04.07.2019 16:16, Andrew Cooper wrote:
> On 04/07/2019 15:10, Andrew Cooper wrote:
>> On 01/07/2019 12:18, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -9100,6 +9100,133 @@ x86_emulate(
>>>put_stub(stub);
Introduce XenPlatformPei, a copy of OvmfPkg/PlatformPei without some
of QEMU specific initialization, Xen does not support QemuFwCfg.
This new module will be adjusted to accommodate Xen PVH.
fw_cfg dependents that have been removed, which are dynamically skipped
when running PlatformPei on Xen:
-
OvmfXen is a copy of OvmfX64, removing VirtIO and some SMM.
This new platform will be changed to make it works on two types of Xen
guest: HVM and PVH.
Compare to OvmfX64, this patch:
- changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
- removed: VirtioLib class resolution
- removed: all
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/ovmf.git br.platform-xen-pvh-v3
Hi,
I've started to create a Xen specific platform, in OvmfPkg/XenOvmf.dsc
with the goal to make it work on both Xen HVM and Xen PVH.
The first few patches only create the p
As described in the Xen PVH documentation [1], "ebx: contains the
physical memory address where the loader has placed the boot start info
structure". To have this pointer saved to be able to use it later in the
PEI phase, we allocate some space in the MEMFD for it. We use 'XPVH' as
a signature (for
This patch allows the ResetVector to be run indenpendently from build
time addresses.
The goal of the patch is to avoid having to create RAM just below 4G
when creating a Xen PVH guest while being compatible with the way
hvmloader currently load OVMF, just below 4G.
Only the new PVH entry point w
Add missing dependency on PciLib
and remove extra includes of OvmfPlatforms.h.
Signed-off-by: Anthony PERARD
Reviewed-by: Laszlo Ersek
---
Notes:
v2:
- also add PciLib.h include to the .c
- and remove extra include of OvmfPlatforms.h
OvmfPkg/Library/ResetSystemLib/ResetSystemLib.i
This patch changes the flash device image of OvmfXen to make it look
like it's an ELF. For this, we replace the empty embedded variable store
by a binary array, which is a ELF file header.
The ELF header explain to a loader to load the binary at the address
1MB, then jump to the PVH entry point wh
ACPI Timer does not work in a PVH guest, but local APIC works on both
PVH and HVM.
Note that the use of SecPeiDxeTimerLibCpu might be an issue with a
driver of type DXE_RUNTIME_DRIVER. I've attemptde to find out which of
the DXE_RUNTIME_DRIVER uses the TimerLib at runtime. I've done that by
replac
Introduce XenResetVector, a copy of OvmfPkg/ResetVector, with one
changes:
- SEC_DEFAULT_CR0: enable cache (bit 30 or CD set to 0)
Xen copies the OVMF code to RAM, there is no need to disable cache.
This new module will later be modified to add a new entry point, more
detail in a following comm
Add a new entry point for Xen PVH that enter directly in 32bits.
Information on the expected state of the machine when this entry point
is used can be found at:
https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Antho
On 01/07/2019 12:20, Jan Beulich wrote:
> +/* Clear untouched parts of the mask value. */
> +n = 1 << (4 - ((b & 1) | evex.w));
> +op_mask &= (1 << n) - 1;
> +
> +for ( i = 0; rc == X86EMUL_OKAY && op_mask; ++i )
> +{
> +signed long idx = b & 1 ?
On 01/07/2019 12:22, Jan Beulich wrote:
> --- a/xen/tools/gen-cpuid.py
> +++ b/xen/tools/gen-cpuid.py
> @@ -268,7 +268,7 @@ def crunch_numbers(state):
> # AVX512 extensions acting on vectors of bytes/words are made
> # dependents of AVX512BW (as to requiring wider than 16-bit ma
On 01/07/2019 12:23, Jan Beulich wrote:
> A decoder adjustment is needed here because of the current sharing of
> table entries between different (implied) opcode prefixes: The same
> major opcodes are used for vfmsub{132,213}{p,s}{s,d}, which have a
> different memory operand size and different Di
On 01/07/2019 12:24, Jan Beulich wrote:
> Along the lines of the 4FMAPS case, convert the 4VNNIW-based table
> entries to a decoder adjustment. Because of the current sharing of table
> entries between different (implied) opcode prefixes and with the same
> major opcodes being used for vp4dpwssd{,s
On 04.07.2019 16:44, Andrew Cooper wrote:
> On 01/07/2019 12:20, Jan Beulich wrote:
>> +/* Clear untouched parts of the mask value. */
>> +n = 1 << (4 - ((b & 1) | evex.w));
>> +op_mask &= (1 << n) - 1;
>> +
>> +for ( i = 0; rc == X86EMUL_OKAY && op_mask; ++i )
>> +
This new XenHvmloaderDetected() return true if the hvmloader firmware
has runned before OVMF.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
Notes:
v3:
- Added one sentence in the commit message.
OvmfPkg/XenPlatformPei
When running as a Xen PVH guest, there is no CMOS to read the memory
size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can
works without CMOS by reading the e820 table.
Rework XenPublishRamRegions for PVH, handle the Reserve type and explain
about the ACPI type. MTRR settings aren't
This patch replace the XenDetected() function by the one in
XenPlatformLib.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
---
Notes:
v3:
- new patch, splited from the next patch
(which was OvmfPkg/AcpiPlatformDxe: Use PVH RSDP if exist)
Ov
If the firmware have been started via the Xen PVH entry point, a RSDP
pointer would have been provided. Use it.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
---
Notes:
v3:
- patch splited from the previous one
- Fix DEBUG format string, use %
EFI_XEN_OVMF_INFO is only useful to retrieve the E820 table. The
mXenHvmloaderInfo isn't used yet, but will be use in a further patch to
retrieve the E820 table.
Also remove the unused pointer from the XenInfo HOB as that information
is only useful in the XenPlatformPei.
Ref: https://bugzilla.tia
When the device ID of the host bridge is unknown, check if we are
running as a PVH guest as there is no PCI bus in that case.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
---
Notes:
v3:
- Remove use of XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID, and simpl
"PcAtChipsetPkg/8254TimerDxe" is replaced with a Xen-specific
EFI_TIMER_ARCH_PROTOCOL implementation. Also remove
8259InterruptControllerDxe as it is not used anymore.
This Timer uses the local APIC timer as time source as it can work on
both a Xen PVH guest and an HVM one.
Based on the "PcAtChip
We are going to need to make an hypercall in order to retreive the E820
table from the hypervisor before been able to setup the memory.
Calling XenConnect earlier will allow to setup the XenHypercallLib
earlier to allow to make hypercalls.
While here, add some comments in XenConnect().
Ref: http
The purpose of XenPlatformLib is to regroup the few functions that are
used in several places to detect if Xen is detected, and to get the
XenInfo HOB.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
---
Notes:
v3:
- use SPDX
- add XenPlatformLi
Use the already checked pointer mXenHvmloaderInfo to retrieve the E820
table produced by hvmloader.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
OvmfPkg/XenPlatformPei/Xen.c | 18 +-
1 file changed, 9 insertion
Move XenRealTimeClockLib from ArmVirtPkg to OvmfPkg so it can be used
from the OvmfPkg by the following patch, "OvmfPkg/OvmfXen: use
RealTimeClockRuntimeDxe from EmbeddedPkg"
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Reviewed-by: Laszlo Ersek
---
Not
We are going to replace XenDetected() implementation in
PlatformBootManagerLib by the one in XenPlatformLib.
PlatformBootManagerLib's implementation does cache the result of
GetFirstGuidHob(), so we do something similar in XenPlatformLib.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Si
XenPvhDetected() can be used to figure out if OVMF has started via the
Xen PVH entry point.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
OvmfPkg/XenPlatformPei/Platform.h | 5 +
OvmfPkg/XenPlatformPei/Xen.c | 13
Allow to use Xen hypercalls earlier, during the PEIM stage, but
XenHypercallLibInit() must be called once the XenInfo HOB is created
with the HyperPage setup.
Change the return value of XenHypercallLibInit so failure can be
detected when the call shouldn't fail, but still have the constructor
alwa
Linux panic if the VGA region isn't reserved.
When Linux is booted on EFI system, it expects the memory at 0xa to
_not_ be conventional memory. Otherwise a variable isn't initialised
properly and Linux panic when a virtual console/terminal is asked to be
created.
See for more detail:
https://
XenIoPvhDxe use XenIoMmioLib to reserve some space to be use by the
Grant Tables.
The call is only done if it is necessary, we simply detect if the
guest is PVH, as in this case there is currently no PCI bus, and no
PCI Xen platform device which would start the XenIoPciDxe and allocate
the space f
The XenPlatformPei needs to make hypercalls, but the XenHypercallLib was
initialised before the HyperPage was ready. Now that XenPlatformPei has
initialised the HyperPage, reinitialise the XenHypercallLib.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
---
PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib
implementation. It will also be used by XenTimerDxe. Override
PcdFSBClock to match Xen vLAPIC timer frequency.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
Notes:
v
Replace the XenDetected() implementation by the one from
XenPlatformLib.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
---
Notes:
v3:
- new patch
.../PlatformBootManagerLib.inf| 1 +
.../PlatformBootManagerLib/BdsPlatform.c
On a Xen PVH guest, none of the existing serial or console interface
works, so we add a new one, based on XenConsoleSerialPortLib, and
implemented via SerialDxe.
That is a simple console implementation that can works on both PVH
guest and HVM guests, even if it rarely going to be use on HVM.
Have
When running in a Xen PVH guest, there's nothing to do in
PciAcpiInitialization() because there isn't any PCI bus. When the Host
Bridge DID isn't recognised, simply continue. (The value of
PcdOvmfHostBridgePciDevId would be 0 because it isn't set.)
Ref: https://bugzilla.tianocore.org/show_bug.cgi?
A Xen PVH guest doesn't have a RTC that OVMF would expect, so
PcatRealTimeClockRuntimeDxe fails to initialize and prevent the
firmware from finish to boot. To prevent that, we will use
XenRealTimeClockLib which simply always return the same time.
This will work on both Xen PVH and HVM guests.
Ref:
When the Xen PVH entry point has been used, hvmloader hasn't run and
hasn't prepared an E820 table. The only way left to get an E820 table
is to ask Xen via an hypercall, the call can only be made once so keep
the result cached for later.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Si
Check if there's a start of the day struct provided to PVH guest, save
the ACPI RSDP address for later.
This patch import import arch-x86/hvm/start_info.h from xen.git.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
Notes:
The informations to make a XENMEM_memory_map hypercall is copied over
from the public header of the Xen Project, with the type name modified
to build on OVMF.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
Notes:
v3:
- e
On 04.07.2019 16:47, Andrew Cooper wrote:
> On 01/07/2019 12:22, Jan Beulich wrote:
>> --- a/xen/tools/gen-cpuid.py
>> +++ b/xen/tools/gen-cpuid.py
>> @@ -268,7 +268,7 @@ def crunch_numbers(state):
>># AVX512 extensions acting on vectors of bytes/words are made
>># dependent
Reserve hvmloader's memory only when it has run.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD
Acked-by: Laszlo Ersek
---
Notes:
v3:
- fix empty commit message body
OvmfPkg/XenPlatformPei/Xen.c | 4 +++-
1 file changed, 3 insertions(+), 1 delet
On 01/07/2019 12:26, Jan Beulich wrote:
> As to the feature dependency adjustment, while strictly speaking SSE is
> a sufficient prereq (to have XMM registers), vectors of bytes and qwords
> have got introduced only with SSE2. gcc, for example, uses a similar
> connection in its respective intrinsi
Those macros where introduced when a prefix "xen_" was added to
mb,rmb,wmb. There are gated on __XEN_INTERFACE_VERSION__, but there
are not part of the Xen interface. Users of ring.h needs to provide
xen_[rw]?mb() anywai because [rw]?mb() isn't likely to exist.
Suggested-by: Paul Durrant
Signed-o
The xen_[rw]?mb() macros defined in ring.h can't be used and the fact
that there are gated behind __XEN_INTERFACE_VERSION__ means that it
needs to be defined somewhere. QEMU doesn't implement interfaces with
the Xen hypervisor so defining __XEN_INTERFACE_VERSION__ is pointless.
This leads to:
i
On 04.07.2019 17:15, Anthony PERARD wrote:
> Those macros where introduced when a prefix "xen_" was added to
> mb,rmb,wmb. There are gated on __XEN_INTERFACE_VERSION__, but there
> are not part of the Xen interface. Users of ring.h needs to provide
> xen_[rw]?mb() anywai because [rw]?mb() isn't lik
> -Original Message-
> From: Jan Beulich
> Sent: 04 July 2019 16:49
> To: Anthony Perard
> Cc: xen-devel@lists.xenproject.org; Paul Durrant ;
> Konrad Rzeszutek Wilk
> ; Juergen Gross
> Subject: Re: [Xen-devel] [PATCH] include/public/io/ring.h: Remove xen_mb,
> xen_rmb, xen_wmb macros
flight 138752 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138752/
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 1
write_full_gdt_ptes() has a latent bug. Using virt_to_mfn() and iterating
with (mfn + i) is wrong, because of PDX compression. The context switch path
only functions correctly because NR_RESERVED_GDT_PAGES is 1.
As this is exceedingly unlikely to change moving foward, drop the loop
rather than i
On 04/07/2019 15:25, Jan Beulich wrote:
> On 04.07.2019 16:16, Andrew Cooper wrote:
>> On 04/07/2019 15:10, Andrew Cooper wrote:
>>> On 01/07/2019 12:18, Jan Beulich wrote:
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -9100,6 +9100,133
On 04/07/2019 15:50, Jan Beulich wrote:
> On 04.07.2019 16:44, Andrew Cooper wrote:
>> On 01/07/2019 12:20, Jan Beulich wrote:
>>> +/* Clear untouched parts of the mask value. */
>>> +n = 1 << (4 - ((b & 1) | evex.w));
>>> +op_mask &= (1 << n) - 1;
>>> +
>>> +for ( i
On 04/07/2019 15:54, Jan Beulich wrote:
> On 04.07.2019 16:47, Andrew Cooper wrote:
>> On 01/07/2019 12:22, Jan Beulich wrote:
>>> --- a/xen/tools/gen-cpuid.py
>>> +++ b/xen/tools/gen-cpuid.py
>>> @@ -268,7 +268,7 @@ def crunch_numbers(state):
>>># AVX512 extensions acting on vectors of
On 04/07/2019 15:22, Jan Beulich wrote:
> On 04.07.2019 16:10, Andrew Cooper wrote:
>> On 01/07/2019 12:18, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -9100,6 +9100,133 @@ x86_emulate(
>>>put_stub(stub);
>>
flight 138732 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138732/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 138615
test-amd64-i386-xl-pvshim12 guest-
On 21/06/2019 10:36, Andrew Cooper wrote:
> It is inefficient to call into a different translation unit for a stub
> function, when a static inline will work fine. Replace an open-coded
> printk_once() while moving it.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Stefano
Atomic operations are expensive to use, especially following XSA-295 for ARM.
It is wasteful to use two of them back-to-back when one will do.
Especially for a misbehaving guest on ARM, this will reduce the system
disruption required to complete the grant operations.
Signed-off-by: Andrew Cooper
To allow for further improvements, it is useful to be able to clear more than
a single flag at once. Rework gnttab_clear_flag() into gnttab_clear_flags()
which takes a bitmask rather than a bit number.
No practical change yet.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: R
Please ignore this. I had an error trying to merge a single v2 patch
into an existing series.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
flight 138724 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138724/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 138710
test-amd64-amd64-xl-
flight 138753 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138753/
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 1
flight 138735 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138735/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 133580
test-amd64-i386-qem
flight 138736 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138736/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx broken
Tests which did
flight 138741 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138741/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e54ce6d074283b568a1285034abb794ec0dff1f1
baseline version:
ovmf 4286eb22f4aec33b90574
On 04.07.19 19:57, Andrew Cooper wrote:
write_full_gdt_ptes() has a latent bug. Using virt_to_mfn() and iterating
with (mfn + i) is wrong, because of PDX compression. The context switch path
only functions correctly because NR_RESERVED_GDT_PAGES is 1.
As this is exceedingly unlikely to change
93 matches
Mail list logo
