Hi Bertrand,
On Thu, Jul 14, 2022 at 11:51 AM Bertrand Marquis
wrote:
>
> Hi Jens,
>
> > On 22 Jun 2022, at 14:42, Jens Wiklander wrote:
> >
> > Adds a FF-A version 1.1 [1] mediator to communicate with a Secure
> > Partition in secure world.
> >
> > The implementation is the bare minimum to be a
Hi Julien,
On Fri, Jul 8, 2022 at 9:54 PM Julien Grall wrote:
>
> Hi Jens,
>
> This is the second part of the review.
>
> On 22/06/2022 14:42, Jens Wiklander wrote:
> > +static int get_shm_pages(struct domain *d, struct ffa_shm_mem *shm,
> > + struct ffa_address_range *ran
On 27.07.2022 03:19, Gao, Ruifeng wrote:
> Problem Description:
> Trying to execute "/usr/local/sbin/xen-hptool cpu-offline ", the host
> will hang immediately.
>
> Version-Release and System Details:
> Platform: Ice Lake Server
> Host OS: Red Hat Enterprise Linux 8.3 (Ootpa)
> Kernel: 5.19.0-rc6
On 29.04.2022 16:09, Dario Faggioli wrote:
> On Fri, 2022-04-29 at 14:16 +0200, Jan Beulich wrote:
>> On 29.04.2022 12:52, Dario Faggioli wrote:
Is that mainly
to have a way to record preferences even when all preferred CPUs
are
offline, to be able to go back to the preferences
On 26.07.2022 20:07, Julien Grall wrote:
> On 19/07/2022 17:36, Daniel P. Smith wrote:
>> On 7/15/22 15:16, Julien Grall wrote:
>>> On 06/07/2022 22:04, Daniel P. Smith wrote:
index 498625eae0..834b1ad16b 100644
--- a/xen/arch/x86/guest/xen/pvh-boot.c
+++ b/xen/arch/x86/guest/xen/pvh
On 27.07.2022 02:10, Stefano Stabellini wrote:
> On Tue, 26 Jul 2022, Jan Beulich wrote:
>> You forgot the imo better intermediate option of using the "X" constraint.
>
> I couldn't get "X" to compile in any way (not even for arm64). Do you
> have a concrete example that you think should work usin
flight 171867 xen-4.16-testing real [real]
flight 171876 xen-4.16-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171867/
http://logs.test-lab.xenproject.org/osstest/logs/171876/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
On 7/27/22 03:10, Stefano Stabellini wrote:
On Tue, 26 Jul 2022, Jan Beulich wrote:
On 26.07.2022 02:33, Stefano Stabellini wrote:
On Mon, 25 Jul 2022, Xenia Ragiadakou wrote:
On 7/25/22 09:32, Jan Beulich wrote:
On 24.07.2022 19:20, Xenia Ragiadakou wrote:
On 7/7/22 10:55, Jan Beulich wro
flight 171866 xen-4.15-testing real [real]
flight 171875 xen-4.15-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171866/
http://logs.test-lab.xenproject.org/osstest/logs/171875/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
flight 171865 xen-4.14-testing real [real]
flight 171874 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171865/
http://logs.test-lab.xenproject.org/osstest/logs/171874/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
On Mon, 25 Jul 2022, Smith, Jackson wrote:
> Hi Stefano,
>
> My colleague Jason Lei and I would like to submit a patch to imagebuilder.
>
> It seems that generating a .fit with a true dom0less configuration fails
> because an extraneous comma is included in the its file.
>
> We believe this cha
On Tue, 26 Jul 2022, Jan Beulich wrote:
> On 26.07.2022 02:33, Stefano Stabellini wrote:
> > On Mon, 25 Jul 2022, Xenia Ragiadakou wrote:
> >> On 7/25/22 09:32, Jan Beulich wrote:
> >>> On 24.07.2022 19:20, Xenia Ragiadakou wrote:
> On 7/7/22 10:55, Jan Beulich wrote:
> > On 07.07.2022 09:
On 7/26/22 8:56 AM, Jane Malalane wrote:
+/* Setup per-vCPU vector-type callbacks and trick toolstack to think
+ * we are enlightened. If this setup is unavailable, fallback to the
+ * global vector-type callback. */
Comment style.
+static __init void xen_init_setup_upcall_vector(void)
flight 171870 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171870/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2022-33745 / XSA-408
version 3
insufficient TLB flush for x86 PV guests in shadow mode
UPDATES IN VERSION 3
Update hash for metadata file.
ISSUE DES
flight 171862 xen-unstable real [real]
flight 171869 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171862/
http://logs.test-lab.xenproject.org/osstest/logs/171869/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm6
Enable CONFIG_STATIC_MEMORY in the existing arm64 build.
Create a new test job, called qemu-smoke-arm64-gcc-staticmem.
Adjust qemu-smoke-arm64.sh script to accomodate the static memory test as a
new test variant. The test variant is determined based on the first argument
passed to the script. For
This patch series
- removes all the references to the XEN_CONFIG_EXPERT environmental variable
which is not used anymore
- creates a trivial arm64 test job that boots xen on qemu with dom0 and a
direct mapped dom0less domu with static memory and verifies that domu's memory
ranges are the same as th
The EXPERT config option cannot anymore be selected via the environmental
variable XEN_CONFIG_EXPERT. Remove stale references to XEN_CONFIG_EXPERT
from the automation code.
Signed-off-by: Xenia Ragiadakou
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- add Stefano's R-b tag
automation/bu
flight 171863 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171863/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 171749
test-amd64-amd64-xl-qemuu-win7-amd6
Hi Jan,
On 25/07/2022 17:18, Jan Beulich wrote:
On 25.07.2022 18:05, Julien Grall wrote:
(Sorry for the formatting)
No issues seen.
Good to know. I sent it from my phone and the gmail app used to mangle
e-mails.
On Mon, 25 Jul 2022, 14:10 Jan Beulich, wrote:
Quite obviously to dete
On 26/07/2022 18:54, Luca Fancellu wrote:
Hi Julien,
Hi Luca,
/* Get the index in the rank */
- offset &= virq & INTERRUPT_RANK_MASK;
+ offset = virq & INTERRUPT_RANK_MASK;
AFAICT, vgic_fetch_irouter() has the same problem. Can you update it here as
well?
I think that function is ok, be
Hi Daniel,
On 19/07/2022 17:36, Daniel P. Smith wrote:
On 7/15/22 15:16, Julien Grall wrote:
Hi Daniel,
On 06/07/2022 22:04, Daniel P. Smith wrote:
For x86 the number of allowable multiboot modules varies between the
different
entry points, non-efi boot, pvh boot, and efi boot. In the case o
Hi Julien,
>> /* Get the index in the rank */
>> - offset &= virq & INTERRUPT_RANK_MASK;
>> + offset = virq & INTERRUPT_RANK_MASK;
>
> AFAICT, vgic_fetch_irouter() has the same problem. Can you update it here as
> well?
I think that function is ok, because in there we have:
/* There is exactl
Hi,
Title: I would suggest to mention the irouter in the title.
On 15/07/2022 11:46, Hongda Deng wrote:
When vgic performs irouter registers emulation, to get the target vCPU
via virq conveniently, Xen doesn't store the irouter value directly,
instead it will use the value (affinities) in irout
On 7/25/22 23:25, Jan Beulich wrote:
On 25.07.2022 19:13, Sarah Newman wrote:
A STT_SECTION symbol is not needed if if it is not used as a relocation
target. Therefore, a section, in this case a debug section, may not have
a secsym associated with it.
Signed-off-by: Bill Wendling
Hmm - this
On 21/07/2022 16:37, Rahul Singh wrote:
Hi Julien,
Hi Rahul,
On 21 Jul 2022, at 2:29 pm, Julien Grall wrote:
On 21/07/2022 13:50, Rahul Singh wrote:
Hi Julien,
Hi Rahul,
On 20 Jul 2022, at 12:16 pm, Julien Grall wrote:
Hi Rahul,
On 20/07/2022 10:59, Rahul Singh wrote:
On 13 Jul
Hi,
On 21/07/2022 16:53, Rahul Singh wrote:
On 28 Jun 2022, at 6:23 pm, Mykyta Poturai wrote:
With this patch I get the same results, here is the error message:
(XEN) smmu: /iommu@5140: Unexpected global fault, this could be serious
(XEN) smmu: /iommu@5140:GFSR 0x0001, GFSYNR0
Hi Jan,
On 26/07/2022 17:04, Jan Beulich wrote:
It's hard to imagine a case where an error may legitimately be ignored
here. It's bad enough that in at least one case (set_shadow_status())
the return value was checked only by way of ASSERT()ing.
Signed-off-by: Jan Beulich
Acked-by: Julien Gr
Hi all,
i am able to passthrough usb mass storage to DomUs but only one DomU at a
time.
For passthrough mode, added below parameters in cfg file and is working.
usbctrl=['type=auto, version=2, ports=6']
usbdev=['hostbus=2, hostaddr=2']
Is there a way to share the mass storage between multiple Do
Checks dependent on only d and x can be pulled out, thus allowing to
skip the flush mask calculation.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3020,7 +3020,10 @@ static int _get_page_type(struct page_in
if ( d && shadow_mode_enabled(d) )
While "type" can include PGT_pae_xen_l2, "x" can't, as the bit is
cleared upon de-validation (see also the respective assertion earlier in
the function).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3020,7 +3020,7 @@ static int _get_page_type(struct page_in
Let's use the existing inline wrapper instead of repeating respective
commentary at every site.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -389,7 +389,7 @@ static int oos_remove_write_access(struc
* the page. If that doesn
Now that we're not building multi.c anymore for 2 and 3 guest levels
when !HVM, there's no point in having these conditionals anymore. (As
somewhat a special case, the last of the removed conditionals really
builds on shadow_mode_external() always returning false when !HVM.) This
way the code becom
In my (debug) build this amounts to well over 500 bytes of dead code.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2240,10 +2240,12 @@ void sh_remove_shadows(struct domain *d,
}
It's hard to imagine a case where an error may legitimately be ignored
here. It's bad enough that in at least one case (set_shadow_status())
the return value was checked only by way of ASSERT()ing.
Signed-off-by: Jan Beulich
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -61,7 +61,7 @@
We should not blindly (in a release build) insert the new entry in the
hash if a reference to the guest page cannot be obtained, or else an
excess reference would be put when removing the hash entry again. Crash
the domain in that case instead. The sole caller doesn't further care
about the state o
As of 8cc5036bc385 ("x86/pv: Fix ABAC cmpxchg() race in
_get_page_type()") this no longer needs passing separately - the type
can now be read from struct page_info, as the call now happens after its
writing.
While there also constify the 2nd parameter.
Signed-off-by: Jan Beulich
--- a/xen/arch/
flight 171864 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171864/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Perhaps not entirely unexpected the work there has turned up a few
further items which want dealing with. Most if not all of these
aren't interdependent, so could probably be looked at (and go in)
in (about) any order.
There's one more change I'd like to make, but I didn't get around
to making (tr
On 26.07.2022 17:42, Andrew Cooper wrote:
> On 26/07/2022 16:33, Jan Beulich wrote:
>> On 26.07.2022 17:28, Edwin Török wrote:
>>> The latest Intel manual now says the X2APIC reserved range is only
>>> 0x800 to 0x8ff (NOT 0xbff).
>>> This changed between SDM 68 (Nov 2018) and SDM 69 (Jan 2019).
>>>
On 26.07.2022 17:28, Edwin Török wrote:
> The latest Intel manual now says the X2APIC reserved range is only
> 0x800 to 0x8ff (NOT 0xbff).
> This changed between SDM 68 (Nov 2018) and SDM 69 (Jan 2019).
> The AMD manual documents 0x800-0x8ff too.
>
> There are non-X2APIC MSRs in the 0x900-0xbff ra
On 19.07.2022 19:42, Oleksandr Tyshchenko wrote:
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -443,11 +443,27 @@ static int modify_bars(const struct pci_dev *pdev,
> uint16_t cmd, bool rom_only)
> return 0;
> }
>
> +/* TODO: Add proper emulation for all bits of
The latest Intel manual now says the X2APIC reserved range is only
0x800 to 0x8ff (NOT 0xbff).
This changed between SDM 68 (Nov 2018) and SDM 69 (Jan 2019).
The AMD manual documents 0x800-0x8ff too.
There are non-X2APIC MSRs in the 0x900-0xbff range now:
e.g. 0x981 is IA32_TME_CAPABILITY, an archi
On 19.07.2022 19:42, Oleksandr Tyshchenko wrote:
> From: Oleksandr Andrushchenko
>
> Reset the command register when assigning a PCI device to a guest:
> according to the PCI spec the PCI_COMMAND register is typically all 0's
> after reset, but this might not be true for the guest as it needs
> t
On 26.07.22 16:47, Rahul Singh wrote:
> Hi Oleksandr,
Hello Rahul
>
>> On 19 Jul 2022, at 6:42 pm, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> Hi, all!
>>
>> You can find previous discussion at [1].
>>
>> 1. This patch series is focusing on vPCI and adds support for n
On 19.07.2022 19:42, Oleksandr Tyshchenko wrote:
> --- a/xen/arch/arm/vpci.c
> +++ b/xen/arch/arm/vpci.c
> @@ -41,6 +41,16 @@ static int vpci_mmio_read(struct vcpu *v, mmio_info_t
> *info,
> /* data is needed to prevent a pointer cast on 32bit */
> unsigned long data;
>
> +/*
> +
HI Oleksandr,
> On 19 Jul 2022, at 6:42 pm, Oleksandr Tyshchenko wrote:
>
> From: Oleksandr Andrushchenko
>
> Reset the command register when assigning a PCI device to a guest:
> according to the PCI spec the PCI_COMMAND register is typically all 0's
> after reset, but this might not be true f
On 26.07.2022 16:43, Edwin Török wrote:
> --- a/xen/arch/x86/include/asm/msr-index.h
> +++ b/xen/arch/x86/include/asm/msr-index.h
> @@ -148,7 +148,7 @@
> #define MSR_INTERRUPT_SSP_TABLE 0x06a8
>
> #define MSR_X2APIC_FIRST0x0800
> -#define MSR_X2APIC_LAST
On 26.07.2022 16:23, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On 06.07.2022 23:04, Daniel P. Smith wrote:
> This commit is the first step in adopting domain builder. It goes through the
> dom0 creation and construction functions, converting them over to consume
> struct boot_domaain and changes the startup sequence to use the domain builder
> to create and co
Hi Oleksandr,
> On 19 Jul 2022, at 6:42 pm, Oleksandr Tyshchenko wrote:
>
> From: Oleksandr Andrushchenko
>
> At the moment, we always allocate an extra 16 slots for IO handlers
> (see MAX_IO_HANDLER). So while adding IO trap handlers for the emulated
> MSI-X registers we need to explicitly te
Hi Oleksandr,
> On 19 Jul 2022, at 6:42 pm, Oleksandr Tyshchenko wrote:
>
> From: Oleksandr Andrushchenko
>
> There are range sets which should not be printed, so introduce a flag
> which allows marking those as such. Implement relevant logic to skip
> such entries while printing.
>
> While a
On 06.07.2022 23:04, Daniel P. Smith wrote:
> This commit introduces the domain builder configuration FDT parser along with
> the domain builder core for domain creation. To enable domain builder to be a
> cross architecture internal API, a new arch domain creation call is introduced
> for use by t
The latest Intel manual now says the X2APIC reserved range is only
0x800 to 0x8ff (NOT 0xbff). The AMD manual documents 0x800-0x8ff too.
There are non-X2APIC MSRs in the 0x900-0xbff range now:
e.g. 0x981 is IA32_TME_CAPABILITY, an architectural MSR.
The new MSR in this range appears to have been
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/tools/check-endbr.sh | 9 +
1 file changed, 9 insertions(+)
diff --git a/xen/tools/check-endbr.sh b/xen/tools/check-endbr.sh
index b97684ac25e9..bf153a570db4 100755
--- a/xen/tools/check-endbr.sh
On 06.07.2022 23:04, Daniel P. Smith wrote:
> --- /dev/null
> +++ b/xen/arch/x86/include/asm/bootdomain.h
> @@ -0,0 +1,30 @@
> +#ifndef __ARCH_X86_BOOTDOMAIN_H__
> +#define __ARCH_X86_BOOTDOMAIN_H__
> +
> +struct memsize {
> +long nr_pages;
> +unsigned int percent;
> +bool minus;
> +};
On 26.07.2022 14:25, Andrew Cooper wrote:
> To support CET Shadow Stacks, guard pages changed from being holes to being
> read-only. As such, they can be read.
>
> Moreover, they should be included in the integrity check.
As long as they're non-present mappings, I don't think they should be
incl
On 26.07.2022 15:13, Andrew Cooper wrote:
> GCC complains:
>
> arch/x86/cpu/vpmu.c:351:15: error: conflicting types for 'vpmu_save_force';
> have 'void(void *)' with implied 'nocf_check' attribute
> 351 | void cf_check vpmu_save_force(void *arg)
> | ^~~
>
Hi Oleksandr,
> On 19 Jul 2022, at 6:42 pm, Oleksandr Tyshchenko wrote:
>
> From: Oleksandr Tyshchenko
>
> Hi, all!
>
> You can find previous discussion at [1].
>
> 1. This patch series is focusing on vPCI and adds support for non-identity
> PCI BAR mappings which is required while passing t
On 26/07/2022 13:56, Jane Malalane wrote:
> Implement support for the HVMOP_set_evtchn_upcall_vector hypercall in
> order to set the per-vCPU event channel vector callback on Linux and
> use it in preference of HVM_PARAM_CALLBACK_IRQ.
>
> If the per-VCPU vector setup is successful on BSP, use this
GCC complains:
arch/x86/cpu/vpmu.c:351:15: error: conflicting types for 'vpmu_save_force';
have 'void(void *)' with implied 'nocf_check' attribute
351 | void cf_check vpmu_save_force(void *arg)
| ^~~
In file included from ./arch/x86/include/asm/domain.h:1
Implement support for the HVMOP_set_evtchn_upcall_vector hypercall in
order to set the per-vCPU event channel vector callback on Linux and
use it in preference of HVM_PARAM_CALLBACK_IRQ.
If the per-VCPU vector setup is successful on BSP, use this method
for the APs. If not, fallback to the global
On 25/07/2022 21:46, Boris Ostrovsky wrote:
>
> On 7/25/22 6:03 AM, Jane Malalane wrote:
>> On 18/07/2022 14:59, Boris Ostrovsky wrote:
>>> On 7/18/22 4:56 AM, Andrew Cooper wrote:
On 15/07/2022 14:10, Boris Ostrovsky wrote:
> On 7/15/22 5:50 AM, Andrew Cooper wrote:
>> On 15/07/2022
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2022-33745 / XSA-408
version 2
insufficient TLB flush for x86 PV guests in shadow mode
UPDATES IN VERSION 2
Added metadata
Public release.
ISSUE DE
To support CET Shadow Stacks, guard pages changed from being holes to being
read-only. As such, they can be read.
Moreover, they should be included in the integrity check.
Fixes: 60016604739b ("x86/shstk: Rework the stack layout to support shadow
stacks")
Signed-off-by: Andrew Cooper
---
CC: J
On 26.07.2022 13:51, Andrew Cooper wrote:
> On 26/07/2022 07:29, Jan Beulich wrote:
>> On 25.07.2022 19:50, Andrew Cooper wrote:
>>> This is a debug behaviour to identify buggy kernels. Crashing the domain is
>>> the most unhelpful thing to do, because it discards the relevant context.
>>>
>>> Ins
On 26/07/2022 07:29, Jan Beulich wrote:
> On 25.07.2022 19:50, Andrew Cooper wrote:
>> This is a debug behaviour to identify buggy kernels. Crashing the domain is
>> the most unhelpful thing to do, because it discards the relevant context.
>>
>> Instead, inject #GP[0] like other permission errors
On 26.07.2022 12:36, Bertrand Marquis wrote:
> Would it make sense then for me to try a newer linux kernel first ?
While it's almost always worth a try, I can't really tell. That's
precisely the kind of question that maintainers are in a better
position to answer.
Jan
On Wed, Jun 08, 2022 at 04:27:37PM +0200, Peter Zijlstra wrote:
> The whole disable-RCU, enable-IRQS dance is very intricate since
> changing IRQ state is traced, which depends on RCU.
>
> Add two helpers for the cpuidle case that mirror the entry code.
>
> Signed-off-by: Peter Zijlstra (Intel)
[AMD Official Use Only - General]
Hi Christopher,
Thank you for the quick response. Please find answers below.
>> Does audio playback work OK from your Ubuntu dom0?
Yes.
>> Do you know which version of Ubuntu you are using? ('cat /etc/lsb-release')
Ubuntu 22.04 LTS.
>> Do you know which versio
Hi Jan,
> On 26 Jul 2022, at 11:29, Jan Beulich wrote:
>
> On 26.07.2022 09:51, Bertrand Marquis wrote:
>>
>>
>>> On 25 Jul 2022, at 17:16, Jan Beulich wrote:
>>>
>>> On 25.07.2022 17:51, Bertrand Marquis wrote:
On our CI we have randomly a crash during guest boot on x86.
>>>
>>> Afaic
On 26.07.2022 09:51, Bertrand Marquis wrote:
>
>
>> On 25 Jul 2022, at 17:16, Jan Beulich wrote:
>>
>> On 25.07.2022 17:51, Bertrand Marquis wrote:
>>> On our CI we have randomly a crash during guest boot on x86.
>>
>> Afaict of a PV guest.
>>
>>> We are running on qemu x86_64 using Xen staging.
flight 171861 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171861/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Tue, Jul 26, 2022 at 08:18:40AM +0200, Jan Beulich wrote:
> On 26.07.2022 05:23, Marek Marczykowski-Górecki wrote:
> > This is integration of https://github.com/connojd/xue into mainline Xen.
> > This patch series includes several patches that I made in the process, some
> > are
> > very loosel
flight 171859 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171859/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-libvirt 7 xen-install fail in 171856 pass in 171859
test-amd64-i386-qemuu-rhel6hvm-a
Hi Anthony and other Qemu/Xen guys,
We are trying to enable venus on Xen virtualization platform. And we would
like to use the backend memory with memory-backend-memfd,id=mem1,size=4G
options on QEMU, however, the QEMU will tell us the "-mem-path" is not
supported with Xen. I verified the same fun
> On 25 Jul 2022, at 17:16, Jan Beulich wrote:
>
> On 25.07.2022 17:51, Bertrand Marquis wrote:
>> On our CI we have randomly a crash during guest boot on x86.
>
> Afaict of a PV guest.
>
>> We are running on qemu x86_64 using Xen staging.
>
> Which may introduce unusual timing. An issue ne
78 matches
Mail list logo
