flight 146840 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146840/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
flight 146833 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146833/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
146121
flight 146834 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146834/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
145767
Thanks for all the background information -- this is very much appreciated!
Looking at the level of effort on this one, we ultimately decided to
stick with HVM for our usecase in Project EVE for now.
If there's a customer pressure -- we'll definitely look into picking it back up.
Thanks,
Roman.
flight 146836 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146836/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
flight 146829 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146829/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-i386-xsm
flight 146838 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146838/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 146835 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146835/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 146827 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146827/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-armhf-pvops
On 03/02/2020 14:21, Roger Pau Monné wrote:
> On Mon, Feb 03, 2020 at 01:44:06PM +0100, Sander Eikelenboom wrote:
>> On 03/02/2020 13:41, Roger Pau Monné wrote:
>>> On Mon, Feb 03, 2020 at 01:30:55PM +0100, Sander Eikelenboom wrote:
On 03/02/2020 13:23, Roger Pau Monné wrote:
> On Mon,
On 2/7/20 9:26 AM, Sergey Dyasli wrote:
> From: Ross Lagerwall
>
> Otherwise it produces lots of false positives when a guest starts using
> PV I/O devices.
>
> Signed-off-by: Ross Lagerwall
> Signed-off-by: Sergey Dyasli
>
Reviewed-by: Boris Ostrovsky
On 2/7/20 9:26 AM, Sergey Dyasli wrote:
> Introduce and use xen_kasan_* functions that are needed to properly
> initialise KASAN for Xen PV domains. Disable instrumentation for files
> that are used by xen_start_kernel() before kasan_early_init() could
> be called.
>
> This enables to use
On Mon, Feb 10, 2020 at 06:28:29PM +0100, Roger Pau Monne wrote:
> Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
> This greatly increases the performance of TLB flushes when running
> with a high amount of vCPUs as a Xen guest, and is specially important
> when running in
On Mon, Feb 10, 2020 at 06:28:28PM +0100, Roger Pau Monne wrote:
> Adapt the hypervisor ops framework so it can be used with the
> alternative calls framework. So far no hooks are modified to make use
> of the alternatives patching, as they are not in any hot path.
>
> No functional change
flight 146826 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146826/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-amd64-xsm
On Mon, Feb 10, 2020 at 06:39:21PM +, Andrew Cooper wrote:
> Fixes: b25fb1a04e "xen/pvh: Fix segment selector ABI"
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On Mon, Feb 10, 2020 at 06:28:27PM +0100, Roger Pau Monne wrote:
> The TLB clock is helpful when running Xen on bare metal because when
> doing a TLB flush each CPU is IPI'ed and can keep a timestamp of the
> last flush.
>
> This is not the case however when Xen is running virtualized, and the
>
Hey Julien,
On 2/8/2020 7:05 AM, Julien Grall wrote:
> Hi Jeff,
>
> As you now handle GICR register, I would drop "dist" from the title.
>
Good catch, I missed this in the title.
> On 04/02/2020 19:51, Jeff Kubascik wrote:
>> Per the ARM Generic Interrupt Controller Architecture Specification
The owner domain of shared pages is dom_cow, use that for get_page
otherwise the function fails to return the correct page under some
situations. The check if dom_cow should be used was only performed in
a subset of use-cases. Fixing the error and simplifying the existing check
since we can't have
The following series implements VM forking for Intel HVM guests to allow for
the fast creation of identical VMs without the assosciated high startup costs
of booting or restoring the VM from a savefile.
JIRA issue: https://xenproject.atlassian.net/browse/XEN-89
The fork operation is implemented
During VM forking we'll copy the parent domain's parameters to the client,
including the HAP shadow memory setting that is used for storing the domain's
EPT. We'll copy this in the hypervisor instead doing it during toolstack launch
to allow the domain to start executing and unsharing memory
Add necessary bits to implement "xl fork-vm" commands. The command allows the
user to specify how to launch the device model allowing for a late-launch model
in which the user can execute the fork without the device model and decide to
only later launch it.
Signed-off-by: Tamas K Lengyel
---
v8:
VM forking is the process of creating a domain with an empty memory space and a
parent domain specified from which to populate the memory when necessary. For
the new domain to be functional the VM state is copied over as part of the fork
operation (HVM params, hap allocation, etc).
Signed-off-by:
Implement hypercall that allows a fork to shed all memory that got allocated
for it during its execution and re-load its vCPU context from the parent VM.
This allows the forked VM to reset into the same state the parent VM is in a
faster way then creating a new fork would be. Measurements show
flight 146832 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146832/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
ARM currently has no restrictions on toolstack and guest access to the entire
HVM_PARAM block. As the paging/monitor/sharing features aren't under security
support, this doesn't need an XSA.
The CALLBACK_IRQ and {STORE,CONSOLE}_{PFN,EVTCHN} details exposed read-only to
the guest, while the
Fixes: b25fb1a04e "xen/pvh: Fix segment selector ABI"
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/hvm/dom0_build.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index
flight 146824 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146824/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvopsbroken
build-amd64
The MMIO registers as already byte offsets. Using them in this form removes
the need to shift their values for use.
It is also inefficient to store both entries and alloc_size (which only differ
by entry_size). Rename alloc_size to size, and drop entries entirely, which
simplifies the
Adapt the hypervisor ops framework so it can be used with the
alternative calls framework. So far no hooks are modified to make use
of the alternatives patching, as they are not in any hot path.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Changes since v3:
- New in this
Introduce a specific flag to request a HVM guest TLB flush, which is
an ASID/VPID tickle that forces a linear TLB flush for all HVM guests.
This was previously unconditionally done in each pre_flush call, but
that's not required: HVM guests not using shadow don't require linear
TLB flushes as Xen
Current implementation of hvm_asid_flush_vcpu is not safe to use
unless the target vCPU is either paused or the currently running one,
as it modifies the generation without any locking.
Fix this by using atomic operations when accessing the generation
field, both in hvm_asid_flush_vcpu_asid and
Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
This greatly increases the performance of TLB flushes when running
with a high amount of vCPUs as a Xen guest, and is specially important
when running in shim mode.
The following figures are from a PV guest running `make -j32
Add shadow and hap implementation specific helpers to perform guest
TLB flushes. Note that the code for both is exactly the same at the
moment, and is copied from hvm_flush_vcpu_tlb. This will be changed by
further patches that will add implementation specific optimizations to
them.
No functional
The current implementation of the hypervisor assisted flush for HAP is
extremely inefficient.
First of all there's no need to call paging_update_cr3, as the only
relevant part of that function when doing a flush is the ASID vCPU
flush, so just call that function directly.
Since
Hello,
The following series aims to improve the TLB flush times when running
nested Xen, and it's specially beneficial when running in shim mode.
Only the HAP guest TLB flush is improved, the shadow paging TLB flush is
left as-is, and can be improved later if there's interest.
For a reference
The TLB clock is helpful when running Xen on bare metal because when
doing a TLB flush each CPU is IPI'ed and can keep a timestamp of the
last flush.
This is not the case however when Xen is running virtualized, and the
underlying hypervisor provides mechanism to assist in performing TLB
flushes:
On 10.02.2020 13:09, Roger Pau Monné wrote:
> On Mon, Feb 10, 2020 at 11:42:06AM +, Andrew Cooper wrote:
>> Writing to the stack pointer in the middle of a line of pop operations is
>> specifically recommended against by the optimisation guide, and is a
>> technique
>> used by Speculative
Anthony PERARD writes ("[OSSTEST PATCH] ts-xen-build-prep: Install
python3-dev"):
> Allow to build Xen with python3.
>
> Also, QEMU upstream (to be 4.3) now requires python >= 3.5, but that
> affect only xen-unstable.
>
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
And pushed to
flight 146823 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146823/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-armhf
On 07.02.2020 18:21, Tamas K Lengyel wrote:
> On Fri, Feb 7, 2020 at 10:16 AM Tamas K Lengyel wrote:
>>
>> On Fri, Feb 7, 2020 at 9:54 AM Jan Beulich wrote:
>>>
>>> On 07.02.2020 10:52, Roger Pau Monné wrote:
On Fri, Feb 07, 2020 at 09:08:15AM +0100, Jan Beulich wrote:
> On 06.02.2020
The ASSERT() at the top of csched2_context_saved() is completely
pointless, as the BUG_ON() just in front of it catches the same problem
already.
While at it remove a bogus space in the BUG_ON().
Signed-off-by: Juergen Gross
---
xen/common/sched/credit2.c | 6 ++
1 file changed, 2
On 10.02.2020 16:19, Andrew Cooper wrote:
> On 10/02/2020 15:02, Jan Beulich wrote:
>> On 10.02.2020 15:55, Andrew Cooper wrote:
>>> On 05/02/2020 10:36, Jan Beulich wrote:
On 03.02.2020 15:43, Andrew Cooper wrote:
> --- a/xen/drivers/passthrough/amd/iommu_cmd.c
> +++
Christopher Clark writes ("[PATCH] tools/configure: generate stubs and
long-double 32-bit headers if needed"):
> The gnu/stubs-32.h and bits/long-double-32.h headers are required to
> build hvmloader but are not always available in 64-bit build
> environments. To avoid introducing a build
Christopher Clark writes ("[PATCH 1/2] pygrub: fix python3 cross-compile:
install with INSTALL_PYTHON_PROG"):
> Install pygrub with INSTALL_PYTHON_PROG, as per the other Xen python
> executables, to ensure that the hashbang path to the interpreter
> is written correctly in cross-compile builds,
Christopher Clark writes ("[PATCH 2/2] python, pygrub: pass DISTUTILS env vars
as setup.py args"):
> Allow to respect the target install dir (PYTHON_SITEPACKAGES_DIR)
> as well as other parameters set by the OpenEmbedded build system.
> This is especially useful when the target libdir is not the
Julien Grall writes ("Re: [PATCH] MAINTAINERS: cc community manager on patches
to CHANGELOG.md"):
> Hi,
>
> On 06/02/2020 16:52, Wei Liu wrote:
> > On Thu, Feb 06, 2020 at 04:48:10PM +, Paul Durrant wrote:
> >> The purpose of the change-log is to be a human-readable list of notable
> >>
sched_init_pdata() is used nowhere, it can be removed. Same applies to
the .init_pdata hook of the per-scheduler interface.
Signed-off-by: Juergen Gross
---
xen/common/sched/credit.c | 12
xen/common/sched/credit2.c | 21 -
xen/common/sched/null.c| 10
On 10/02/2020 15:02, Jan Beulich wrote:
> On 10.02.2020 15:55, Andrew Cooper wrote:
>> On 05/02/2020 10:36, Jan Beulich wrote:
>>> On 03.02.2020 15:43, Andrew Cooper wrote:
--- a/xen/drivers/passthrough/amd/iommu_cmd.c
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c
@@ -24,16 +24,14
flight 146828 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146828/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
On 10.02.2020 15:55, Andrew Cooper wrote:
> On 05/02/2020 10:36, Jan Beulich wrote:
>> On 03.02.2020 15:43, Andrew Cooper wrote:
>>> --- a/xen/drivers/passthrough/amd/iommu_cmd.c
>>> +++ b/xen/drivers/passthrough/amd/iommu_cmd.c
>>> @@ -24,16 +24,14 @@ static int queue_iommu_command(struct
On 05/02/2020 10:22, Jan Beulich wrote:
> On 03.02.2020 15:43, Andrew Cooper wrote:
>> The MMIO registers as already byte offsets. By masking out the reserved bits
>> suitably in guest_iommu_mmio_write64(), we can use the values directly,
>> instead of masking/shifting on every use.
> I guess
On 10.02.2020 15:39, Andrew Cooper wrote:
> On 05/02/2020 09:57, Jan Beulich wrote:
>> On 03.02.2020 15:43, Andrew Cooper wrote:
>>> @@ -85,16 +85,14 @@ static void flush_command_buffer(struct amd_iommu
>>> *iommu)
>>> loop_count = 1000;
>>> do {
>>> status =
On 10.02.2020 15:30, Andrew Cooper wrote:
> On 05/02/2020 09:47, Jan Beulich wrote:
>> On 03.02.2020 15:43, Andrew Cooper wrote:
>>> We currently have amd-iommu-defs.h, amd-iommu-proto.h and amd-iommu.h, and
>>> no
>>> references outside of the AMD IOMMU driver.
>>>
>>> Keep iommu-defs.h as is,
On 05/02/2020 10:36, Jan Beulich wrote:
> On 03.02.2020 15:43, Andrew Cooper wrote:
>> --- a/xen/drivers/passthrough/amd/iommu_cmd.c
>> +++ b/xen/drivers/passthrough/amd/iommu_cmd.c
>> @@ -24,16 +24,14 @@ static int queue_iommu_command(struct amd_iommu *iommu,
>> u32 cmd[])
>> {
>> uint32_t
On 10.02.2020 15:06, Andrew Cooper wrote:
> On 10/02/2020 14:00, Jan Beulich wrote:
>> On 10.02.2020 14:56, Andrew Cooper wrote:
>>> On 10/02/2020 13:47, Jan Beulich wrote:
On 10.02.2020 14:29, Andrew Cooper wrote:
> On 10/02/2020 13:22, Jan Beulich wrote:
>> On 08.02.2020 16:19,
On 05/02/2020 09:57, Jan Beulich wrote:
> On 03.02.2020 15:43, Andrew Cooper wrote:
>> @@ -85,16 +85,14 @@ static void flush_command_buffer(struct amd_iommu *iommu)
>> loop_count = 1000;
>> do {
>> status = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
>> -
On 05/02/2020 09:47, Jan Beulich wrote:
> On 03.02.2020 15:43, Andrew Cooper wrote:
>> We currently have amd-iommu-defs.h, amd-iommu-proto.h and amd-iommu.h, and no
>> references outside of the AMD IOMMU driver.
>>
>> Keep iommu-defs.h as is, but merge amd-iommu.h and amd-iommu-proto.h to just
>>
On 05/02/2020 09:43, Jan Beulich wrote:
> Introduce IOMMU_PDE_NEXT_LEVEL_{MIN,MAX} to replace literal 1, 6, and 7
> instances. While doing so replace two uses of memset() by initializers.
>
> Signed-off-by: Jan Beulich
This does not look to be an improvement. IOMMU_PDE_NEXT_LEVEL_MIN is
On 10/02/2020 14:00, Jan Beulich wrote:
> On 10.02.2020 14:56, Andrew Cooper wrote:
>> On 10/02/2020 13:47, Jan Beulich wrote:
>>> On 10.02.2020 14:29, Andrew Cooper wrote:
On 10/02/2020 13:22, Jan Beulich wrote:
> On 08.02.2020 16:19, Andrew Cooper wrote:
>> ---
On 10.02.2020 14:56, Andrew Cooper wrote:
> On 10/02/2020 13:47, Jan Beulich wrote:
>> On 10.02.2020 14:29, Andrew Cooper wrote:
>>> On 10/02/2020 13:22, Jan Beulich wrote:
On 08.02.2020 16:19, Andrew Cooper wrote:
> --- a/docs/misc/pvh.pandoc
> +++ b/docs/misc/pvh.pandoc
> @@
On 05/02/2020 09:42, Jan Beulich wrote:
> The level 1 special exit path is unnecessary in iommu_pde_from_dfn() -
> the subsequent code takes care of this case quite fine.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing
On 10/02/2020 13:47, Jan Beulich wrote:
> On 10.02.2020 14:29, Andrew Cooper wrote:
>> On 10/02/2020 13:22, Jan Beulich wrote:
>>> On 08.02.2020 16:19, Andrew Cooper wrote:
--- a/docs/misc/pvh.pandoc
+++ b/docs/misc/pvh.pandoc
@@ -23,7 +23,7 @@ following machine state:
*
On 05/02/2020 09:42, Jan Beulich wrote:
> amd_iommu_get_paging_mode() expects a count, not a "maximum possible"
> value. Prior to b4f042236ae0 dropping the reference, the use of our mis-
> named "max_page" in amd_iommu_domain_init() may have lead to such a
> misunderstanding.
>
> Also replace a
On 10.02.2020 14:29, Andrew Cooper wrote:
> On 10/02/2020 13:22, Jan Beulich wrote:
>> On 08.02.2020 16:19, Andrew Cooper wrote:
>>> --- a/docs/misc/pvh.pandoc
>>> +++ b/docs/misc/pvh.pandoc
>>> @@ -23,7 +23,7 @@ following machine state:
>>> * `cs`: must be a 32-bit read/execute code segment
On 10/02/2020 13:22, Jan Beulich wrote:
> On 08.02.2020 16:19, Andrew Cooper wrote:
>> --- a/docs/misc/pvh.pandoc
>> +++ b/docs/misc/pvh.pandoc
>> @@ -23,7 +23,7 @@ following machine state:
>> * `cs`: must be a 32-bit read/execute code segment with a base of ‘0’
>> and a limit of
On 07/02/2020 14:36, David Miller wrote:
> From: Sergey Dyasli
> Date: Fri, 7 Feb 2020 14:26:52 +
>
>> From: Ross Lagerwall
>>
>> When KASAN (or SLUB_DEBUG) is turned on, there is a higher chance that
>> non-power-of-two allocations are not aligned to the next power of 2 of
>> the size.
On 08.02.2020 16:19, Andrew Cooper wrote:
> --- a/docs/misc/pvh.pandoc
> +++ b/docs/misc/pvh.pandoc
> @@ -23,7 +23,7 @@ following machine state:
> * `cs`: must be a 32-bit read/execute code segment with a base of ‘0’
> and a limit of ‘0x’. The selector value is unspecified.
>
> - *
Signed-off-by: Ian Jackson
---
production-config | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/production-config b/production-config
index 41f68409..103b8915 100644
--- a/production-config
+++ b/production-config
@@ -90,7 +90,7 @@ TftpNetbootGroup osstest
# Update with
On 10/02/2020 12:32, Jan Beulich wrote:
On 10.02.2020 13:21, Julien Grall wrote:
Hi,
On 10/02/2020 11:59, Jan Beulich wrote:
On 10.02.2020 12:00, Julien Grall wrote:
On 10/02/2020 10:28, Jan Beulich wrote:
On 10.02.2020 10:45, Julien Grall wrote:
Please suggest a new name for BIT_WORD()
On 10/02/2020 12:14, Marek Marczykowski-Górecki wrote:
> On Mon, Feb 10, 2020 at 11:17:34AM +, Andrew Cooper wrote:
>> On 10/02/2020 08:55, Jan Beulich wrote:
>>> On 10.02.2020 00:06, Marek Marczykowski-Górecki wrote:
Hi,
Multiple Qubes users have reported issues with resuming
On Sun, Feb 09, 2020 at 08:35:14PM -0800, Christopher Clark wrote:
> The gnu/stubs-32.h and bits/long-double-32.h headers are required to
> build hvmloader but are not always available in 64-bit build
> environments. To avoid introducing a build requirement on 32-bit
> multilib generate versions
On 10.02.2020 13:21, Julien Grall wrote:
> Hi,
>
> On 10/02/2020 11:59, Jan Beulich wrote:
>> On 10.02.2020 12:00, Julien Grall wrote:
>>> On 10/02/2020 10:28, Jan Beulich wrote:
On 10.02.2020 10:45, Julien Grall wrote:
> Please suggest a new name for BIT_WORD() and we can repurpose it.
Hi,
On 10/02/2020 11:59, Jan Beulich wrote:
On 10.02.2020 12:00, Julien Grall wrote:
On 10/02/2020 10:28, Jan Beulich wrote:
On 10.02.2020 10:45, Julien Grall wrote:
Please suggest a new name for BIT_WORD() and we can repurpose it. So
far, I have no idea how to rename it.
_BIT_WORD() if
On Mon, Feb 10, 2020 at 11:17:34AM +, Andrew Cooper wrote:
> On 10/02/2020 08:55, Jan Beulich wrote:
> > On 10.02.2020 00:06, Marek Marczykowski-Górecki wrote:
> >> Hi,
> >>
> >> Multiple Qubes users have reported issues with resuming from S3 on AMD
> >> systems (Ryzen 2500U, Ryzen Pro 3700U,
flight 146815 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146815/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm broken
build-armhf-pvops
On Mon, Feb 10, 2020 at 11:42:06AM +, Andrew Cooper wrote:
> Writing to the stack pointer in the middle of a line of pop operations is
> specifically recommended against by the optimisation guide, and is a technique
> used by Speculative Load Hardening to combat SpectreRSB.
>
> In practice,
On 10.02.2020 12:00, Julien Grall wrote:
> On 10/02/2020 10:28, Jan Beulich wrote:
>> On 10.02.2020 10:45, Julien Grall wrote:
>>> Please suggest a new name for BIT_WORD() and we can repurpose it. So
>>> far, I have no idea how to rename it.
>>
>> _BIT_WORD() if you/we were to accept the name
Writing to the stack pointer in the middle of a line of pop operations is
specifically recommended against by the optimisation guide, and is a technique
used by Speculative Load Hardening to combat SpectreRSB.
In practice, it causes all further stack-relative accesses to block until the
write to
On 10/02/2020 08:55, Jan Beulich wrote:
> On 10.02.2020 00:06, Marek Marczykowski-Górecki wrote:
>> Hi,
>>
>> Multiple Qubes users have reported issues with resuming from S3 on AMD
>> systems (Ryzen 2500U, Ryzen Pro 3700U, maybe more). The error message
>> is:
>>
>> (XEN) CPU0: cap[ 1] is 7ed8320b
On 10/02/2020 10:28, Jan Beulich wrote:
On 10.02.2020 10:45, Julien Grall wrote:
Please suggest a new name for BIT_WORD() and we can repurpose it. So
far, I have no idea how to rename it.
_BIT_WORD() if you/we were to accept the name space violation, or
BITMAP_WORD()?
BITMAP_WORD() is
On Sat, Feb 08, 2020 at 03:19:39PM +, Andrew Cooper wrote:
> The written ABI states that %es will be set up, but libxc doesn't do so. In
> practice, it breaks `rep movs` inside guests before they reload %es.
>
> The written ABI doesn't mention %ss, but libxc does set it up. Having %ds
>
On 10.02.2020 10:45, Julien Grall wrote:
> Please suggest a new name for BIT_WORD() and we can repurpose it. So
> far, I have no idea how to rename it.
_BIT_WORD() if you/we were to accept the name space violation, or
BITMAP_WORD()?
Jan
___
Xen-devel
flight 146825 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146825/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-armhf
Hi Jan,
On 10/02/2020 09:31, Jan Beulich wrote:
On 10.02.2020 10:20, Julien Grall wrote:
Hi Jan,
On 10/02/2020 08:43, Jan Beulich wrote:
On 08.02.2020 15:37, Julien Grall wrote:
On 05/02/2020 13:27, Jan Beulich wrote:
On 05.02.2020 14:21, Roger Pau Monné wrote:
On Wed, Feb 05, 2020 at
On 10.02.2020 10:20, Julien Grall wrote:
> Hi Jan,
>
> On 10/02/2020 08:43, Jan Beulich wrote:
>> On 08.02.2020 15:37, Julien Grall wrote:
>>>
>>>
>>> On 05/02/2020 13:27, Jan Beulich wrote:
On 05.02.2020 14:21, Roger Pau Monné wrote:
> On Wed, Feb 05, 2020 at 09:46:25AM +0100, Jan
Hi Jan,
On 10/02/2020 08:43, Jan Beulich wrote:
On 08.02.2020 15:37, Julien Grall wrote:
On 05/02/2020 13:27, Jan Beulich wrote:
On 05.02.2020 14:21, Roger Pau Monné wrote:
On Wed, Feb 05, 2020 at 09:46:25AM +0100, Jan Beulich wrote:
On 04.02.2020 18:34, Roger Pau Monne wrote:
Import the
On 10.02.2020 00:06, Marek Marczykowski-Górecki wrote:
> Hi,
>
> Multiple Qubes users have reported issues with resuming from S3 on AMD
> systems (Ryzen 2500U, Ryzen Pro 3700U, maybe more). The error message
> is:
>
> (XEN) CPU0: cap[ 1] is 7ed8320b (expected f6d8320b)
>
> If I read it right,
On 08.02.2020 15:37, Julien Grall wrote:
>
>
> On 05/02/2020 13:27, Jan Beulich wrote:
>> On 05.02.2020 14:21, Roger Pau Monné wrote:
>>> On Wed, Feb 05, 2020 at 09:46:25AM +0100, Jan Beulich wrote:
On 04.02.2020 18:34, Roger Pau Monne wrote:
> Import the functions and it's
89 matches
Mail list logo
