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 dependencies.
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, th
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 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 Beulic
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 09
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
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
> diff
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
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 misl
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
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 t
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 space
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, it
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: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, m
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 you
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. S
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 of
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 fr
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() a
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 ./mg
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.
>
> - *
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. There
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 ‘0x’
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 with
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 lit
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:
* `cs`:
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 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
> @@ -23,
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:
>> --- a/docs/misc/pvh.pandoc
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
definite
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
>> i
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);
>> -comp_wait
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, Andre
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: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, bu
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 = readl(iommu->mmio_b
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 it's
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 amd_iomm
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
build-arm64-xs
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 @@
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 --
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
> >> chang
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 d
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, eg
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 requirem
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
> +++ b/xen/drivers/pas
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 insertion
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 16
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
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 pret
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 Load
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:
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 hvm_asid_flush_vcp
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 ot
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
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 on
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 xen
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
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 ve
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 allocation
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
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 831
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 *_RING
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 1
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:
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 a
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 before
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 abou
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
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
> u
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
https://lists.xenproje
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: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 intende
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 shi
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 Outline
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 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, Feb
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
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 1
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 1
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 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
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 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
test-amd64-i386-xl-qemu
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
test-amd64-i386-xl
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
89 matches
Mail list logo
