On 1/26/21 11:31 PM, Dario Faggioli wrote:
On Tue, 2021-01-26 at 18:03 +0100, Anders Törnqvist wrote:
On 1/25/21 5:11 PM, Dario Faggioli wrote:
On Fri, 2021-01-22 at 14:26 +, Julien Grall wrote:
Hi Anders,
On 22/01/2021 08:06, Anders Törnqvist wrote:
On 1/22/21 12:35 AM, Dario Faggioli w
Keep the dummy handlers for restrict, map_resource and unmap_resource
for MiniOS, or else the build breaks with:
ld:
/home/osstest/build.158759.build-amd64/xen/stubdom/mini-os-x86_64-xenstore/mini-os.o:
in function `xenforeignmemory_restrict':
/home/osstest/build.158759.build-amd64/xen/stubdom/l
On 29/01/2021 08:09, Roger Pau Monne wrote:
> Keep the dummy handlers for restrict, map_resource and unmap_resource
> for MiniOS, or else the build breaks with:
>
> ld:
> /home/osstest/build.158759.build-amd64/xen/stubdom/mini-os-x86_64-xenstore/mini-os.o:
> in function `xenforeignmemory_restrict
> -Original Message-
> From: Jürgen Groß
> Sent: 29 January 2021 07:35
> To: Dongli Zhang ; Paul Durrant ; xen-
> de...@lists.xenproject.org; linux-bl...@vger.kernel.org;
> linux-ker...@vger.kernel.org
> Cc: Paul Durrant ; Konrad Rzeszutek Wilk
> ; Roger Pau
> Monné ; Jens Axboe
> Subje
Hi Oleksandr,
I just tested the v6 and the latest backend service with the latest staging
branch.
They work well.
Tested-by: Wei Chen
Cheers,
Wei Chen
> -Original Message-
> From: Oleksandr Tyshchenko
> Sent: 2021年1月29日 9:48
> To: xen-devel@lists.xenproject.org
> Cc: Oleksandr Tyshc
On 28.01.2021 21:26, Andrew Cooper wrote:
> On 20/01/2021 09:19, Jan Beulich wrote:
>> On 16.01.2021 00:10, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpu/common.c
>>> +++ b/xen/arch/x86/cpu/common.c
>>> @@ -834,6 +834,29 @@ void load_system_tables(void)
>>> BUG_ON(system_state != SYS_STATE_ea
On 29.01.21 09:08, Anders Törnqvist wrote:
On 1/26/21 11:31 PM, Dario Faggioli wrote:
On Tue, 2021-01-26 at 18:03 +0100, Anders Törnqvist wrote:
On 1/25/21 5:11 PM, Dario Faggioli wrote:
On Fri, 2021-01-22 at 14:26 +, Julien Grall wrote:
Hi Anders,
On 22/01/2021 08:06, Anders Törnqvist w
On 29.01.2021 07:51, osstest service owner wrote:
> flight 158759 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/158759/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64
On 28.01.2021 19:26, Dario Faggioli wrote:
> On Thu, 2021-01-14 at 19:02 +, Andrew Cooper wrote:
>> 2) "scheduler broken" bugs. We've had 4 or 5 reports of Xen not
>> working, and very little investigation on whats going on. Suspicion
>> is
>> that there might be two bugs, one with smt=0 on r
On 29.01.2021 09:13, Wei Chen wrote:
> I just tested the v6 and the latest backend service with the latest staging
> branch.
> They work well.
>
> Tested-by: Wei Chen
An faod this was again Arm-only testing?
Jan
On 29.01.2021 02:48, Oleksandr Tyshchenko wrote:
> --- /dev/null
> +++ b/xen/include/xen/dm.h
> @@ -0,0 +1,44 @@
> +/*
> + * Copyright (c) 2016 Citrix Systems Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU Gen
On 29.01.2021 02:48, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This patch prevents the device model running on other than x86
> systems to use buffered I/O feature for now.
>
> Please note, there is no caller which requires to send buffered
> I/O request on Arm currently and t
On 29.01.2021 02:48, Oleksandr Tyshchenko wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -137,7 +137,13 @@ config HYPFS_CONFIG
> want to hide the .config contents from dom0.
>
> config IOREQ_SERVER
> - bool
> + bool "IOREQ support (EXPERT)" if EXPERT && !X86
>
On 29.01.2021 02:48, Oleksandr Tyshchenko wrote:
> Julien Grall (3):
> xen/ioreq: Make x86's IOREQ related dm-op handling common
> xen/mm: Make x86's XENMEM_resource_ioreq_server handling common
> arm/ioreq: Introduce arch specific bits for IOREQ/DM features
>
> Oleksandr Tyshchenko (21):
>
Both the multiboot and the HVM start info structures allow passing a
string together with a module. Implement the missing support in
pvh_load_kernel so that module strings found in the multiboot
structure are forwarded to dom0.
Fixes: 62ba982424 ('x86: parse Dom0 kernel for PVHv2')
Signed-off-by:
On 28.01.2021 17:06, Andrew Cooper wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -1054,7 +1054,7 @@ static long xatp_permission_check(struct domain *d,
> unsigned int space)
> }
>
> static int acquire_grant_table(struct domain *d, unsigned int id,
> -
On Fri, 2021-01-29 at 09:38 +0100, Jan Beulich wrote:
> On 28.01.2021 19:26, Dario Faggioli wrote:
> >
> > Did I forget any?
>
> Going just from my mailbox, where I didn't keep all of the still
> unaddressed reports, but some (another one I have there is among
> the ones you've mentioned above):
On 29.01.2021 10:05, Roger Pau Monne wrote:
> Both the multiboot and the HVM start info structures allow passing a
> string together with a module. Implement the missing support in
> pvh_load_kernel so that module strings found in the multiboot
> structure are forwarded to dom0.
>
> Fixes: 62ba982
On 29/01/2021 09:15, Jan Beulich wrote:
> On 28.01.2021 17:06, Andrew Cooper wrote:
>> --- a/xen/common/memory.c
>> +++ b/xen/common/memory.c
>> @@ -1054,7 +1054,7 @@ static long xatp_permission_check(struct domain *d,
>> unsigned int space)
>> }
>>
>> static int acquire_grant_table(struct dom
On 28.01.2021 23:56, Andrew Cooper wrote:
> On 18/01/2021 08:23, Jan Beulich wrote:
>> On 15.01.2021 17:57, Andrew Cooper wrote:
>>> On 15/01/2021 11:56, Jan Beulich wrote:
> +/* Grow table if necessary. */
> +grant_write_lock(gt);
> +rc = -EINVAL;
> +switch ( id )
>
On 29.01.2021 10:32, Andrew Cooper wrote:
> On 29/01/2021 09:15, Jan Beulich wrote:
>> On 28.01.2021 17:06, Andrew Cooper wrote:
>>> --- a/xen/common/memory.c
>>> +++ b/xen/common/memory.c
>>> @@ -1054,7 +1054,7 @@ static long xatp_permission_check(struct domain *d,
>>> unsigned int space)
>>> }
On 29.01.2021 00:44, Andrew Cooper wrote:
> On 15/01/2021 16:12, Jan Beulich wrote:
>> On 12.01.2021 20:48, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -4628,7 +4628,6 @@ int arch_acquire_resource(struct domain *d, unsigned
>>> int type,
>>> if ( id
On 29/01/2021 09:40, Jan Beulich wrote:
> On 29.01.2021 10:32, Andrew Cooper wrote:
>> On 29/01/2021 09:15, Jan Beulich wrote:
>>> On 28.01.2021 17:06, Andrew Cooper wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1054,7 +1054,7 @@ static long xatp_permission_check(str
On Fri, Jan 29, 2021 at 10:26:31AM +0100, Jan Beulich wrote:
> On 29.01.2021 10:05, Roger Pau Monne wrote:
> > Both the multiboot and the HVM start info structures allow passing a
> > string together with a module. Implement the missing support in
> > pvh_load_kernel so that module strings found in
Hi Oleksandr,
On 29/01/2021 01:48, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The purpose of this patch is to add a possibility for user
to be able to select IOREQ support on Arm (which is disabled
by default) with retaining the current behaviour on x86
(is selected by HVM and it's
On 29.01.2021 10:47, Andrew Cooper wrote:
> On 29/01/2021 09:40, Jan Beulich wrote:
>> On 29.01.2021 10:32, Andrew Cooper wrote:
>>> What's the likelihood that you'll choose to backport this?
>> Didn't consider this aspect yet. I think I wouldn't have picked
>> it without anyone asking for it to be
On 29/01/2021 10:01, Jan Beulich wrote:
> On 29.01.2021 10:47, Andrew Cooper wrote:
>> On 29/01/2021 09:40, Jan Beulich wrote:
>>> On 29.01.2021 10:32, Andrew Cooper wrote:
What's the likelihood that you'll choose to backport this?
>>> Didn't consider this aspect yet. I think I wouldn't have p
Hi,
On 29/01/2021 01:48, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds ability to the device emulator to notify otherend
(some entity running in the guest) using a SPI and implements Arm
specific bits for it. Proposed interface allows emulator to set
the logical level
On 29.01.2021 10:55, Julien Grall wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -137,7 +137,13 @@ config HYPFS_CONFIG
>>want to hide the .config contents from dom0.
>>
>> config IOREQ_SERVER
>> -bool
>> +bool "IOREQ support (EXPERT)" if EXPERT && !X86
>>
Hi Oleksandr,
On 29/01/2021 01:48, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
In order to avoid code duplication (both handle_read() and
handle_ioserv() contain the same code for the sign-extension)
put this code to a common helper to be used for both.
Signed-off-by: Oleksandr Tys
On 29.01.2021 11:04, Andrew Cooper wrote:
> On 29/01/2021 10:01, Jan Beulich wrote:
>> On 29.01.2021 10:47, Andrew Cooper wrote:
>>> On 29/01/2021 09:40, Jan Beulich wrote:
On 29.01.2021 10:32, Andrew Cooper wrote:
> What's the likelihood that you'll choose to backport this?
Didn't co
flight 158768 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158768/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 158713
Tests which
On Fri, 2021-01-29 at 09:18 +0100, Jürgen Groß wrote:
> On 29.01.21 09:08, Anders Törnqvist wrote:
> > >
> > > So it using it has only downsides (and that's true in general, if
> > > you
> > > ask me, but particularly so if using NULL).
> > Thanks for the feedback.
> > I removed dom0_vcpus_pin. An
Hi Oleksandr,
On 29/01/2021 01:48, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch prevents the device model running on other than x86
systems to use buffered I/O feature for now.
Please note, there is no caller which requires to send buffered
I/O request on Arm currently an
> -Original Message-
> From: Oleksandr Tyshchenko
> Sent: 29 January 2021 01:49
> To: xen-devel@lists.xenproject.org
> Cc: Oleksandr Tyshchenko ; Paul Durrant
> ; Julien Grall
> ; Stefano Stabellini ; Andrew Cooper
>
> Subject: [PATCH V6 23/24] xen/ioreq: Do not let bufioreq to be used o
On 25.01.2021 16:37, Igor Druzhinin wrote:
> On 12/01/2021 04:17, Igor Druzhinin wrote:
>> TLFS 7.8.1 stipulates that "a virtual processor index must be less than
>> the maximum number of virtual processors per partition" that "can be obtained
>> through CPUID leaf 0x4005". Furthermore, "Requir
Hi Jan,
On 29/01/2021 09:04, Jan Beulich wrote:
On 29.01.2021 02:48, Oleksandr Tyshchenko wrote:
Julien Grall (3):
xen/ioreq: Make x86's IOREQ related dm-op handling common
xen/mm: Make x86's XENMEM_resource_ioreq_server handling common
arm/ioreq: Introduce arch specific bits for IOREQ
Julien Grall writes ("[TOOLS ACK needed] Re: [PATCH V6 18/24] xen/dm: Introduce
xendevicemodel_set_irq_level DM op"):
> On 29/01/2021 01:48, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko
> >
> > This patch adds ability to the device emulator to notify otherend
...
> > Signed-off-by:
On Tue, Jan 26, 2021 at 05:22:59PM +, Andrew Cooper wrote:
> On 20/01/2021 11:03, Greg KH wrote:
> > On Mon, Jan 18, 2021 at 03:04:26PM +0100, Roger Pau Monne wrote:
> >> commit ef3a575baf53571dc405ee4028e26f50856898e7 upstream
> >>
> >> Allow issuing an IOCTL_PRIVCMD_MMAP_RESOURCE ioctl with n
> -Original Message-
> From: Igor Druzhinin
> Sent: 12 January 2021 04:17
> To: xen-devel@lists.xenproject.org
> Cc: i...@xenproject.org; w...@xen.org; andrew.coop...@citrix.com;
> george.dun...@citrix.com;
> jbeul...@suse.com; jul...@xen.org; sstabell...@kernel.org;
> anthony.per...@cit
> -Original Message-
> From: Jan Beulich
> Sent: 29 January 2021 10:31
> To: p...@xen.org; i...@xenproject.org; w...@xen.org; anthony.per...@citrix.com
> Cc: andrew.coop...@citrix.com; george.dun...@citrix.com; jul...@xen.org;
> sstabell...@kernel.org;
> roger@citrix.com; xen-devel@li
On 29.01.21 10:13, Wei Chen wrote:
Hi Oleksandr,
Hi Wei
I just tested the v6 and the latest backend service with the latest staging
branch.
They work well.
Tested-by: Wei Chen
Thank you, I appreciate your help!
Cheers,
Wei Chen
-Original Message-
From: Oleksandr Tyshc
On Thu, Jan 28, 2021 at 12:01:52PM +, Andrew Cooper wrote:
> With the Xen side of this interface (soon to be) fixed to return real sizes,
> userspace needs to be able to make the query.
>
> Introduce xenforeignmemory_resource_size() for the purpose, bumping the
> library minor version.
>
> Up
On Thu, Jan 28, 2021 at 11:08:08AM +, Andrew Cooper wrote:
> On 28/01/2021 10:57, Roger Pau Monné wrote:
> > On Tue, Jan 26, 2021 at 11:47:59PM +0100, Manuel Bouyer wrote:
> >> On NetBSD, PTHREAD_STACK_MIN is not available.
> >> If PTHREAD_STACK_MIN is not defined, define it to 0 so that we fal
... in order to reuse stgi elsewhere.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/hvm/svm/entry.S| 10 +++---
xen/include/asm-x86/asm-defns.h | 12
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/xen/ar
On Thu, Jan 28, 2021 at 12:08:02PM +0100, Roger Pau Monné wrote:
> On Tue, Jan 26, 2021 at 11:47:58PM +0100, Manuel Bouyer wrote:
> > Pass bridge name to qemu as command line option
> > When starting qemu, set an environnement variable XEN_DOMAIN_ID,
> > to be used by qemu helper scripts
> > The on
SMMUv3 driver does not support ACPI device probe.If APCI is enabled with
SMMUv3 driver compiler will throw an error.
Disable SMMUv3 driver when ACPI is enabled in kconfig to fix compilation
error.
Signed-off-by: Rahul Singh
---
xen/drivers/passthrough/Kconfig | 2 +-
1 file changed, 1 insertion
On Thu, Jan 28, 2021 at 11:42:45AM +, Andrew Cooper wrote:
> FAOD I've committed a fixed up version of this patch as discussed.
thanks !
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
On 29.01.21 10:49, Jan Beulich wrote:
Hi Jan
On 29.01.2021 09:13, Wei Chen wrote:
I just tested the v6 and the latest backend service with the latest staging
branch.
They work well.
Tested-by: Wei Chen
An faod this was again Arm-only testing?
Yes, unfortunately I don't have a possibility
> On Jan 28, 2021, at 10:56 PM, George Dunlap wrote:
>
>
>
>> On Jan 28, 2021, at 10:42 PM, George Dunlap wrote:
>>
>>
>>
>>> On Jan 28, 2021, at 6:26 PM, Elliott Mitchell wrote:
>>>
>>> On Thu, Jan 28, 2021 at 11:19:41AM +0100, Jan Beulich wrote:
On 27.01.2021 23:28, Elliott Mitch
flight 158761 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158761/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On Thu, Jan 28, 2021 at 12:21:33PM +0100, Roger Pau Monné wrote:
> On Tue, Jan 26, 2021 at 11:47:50PM +0100, Manuel Bouyer wrote:
> > On NetBSD use the system-provided headers for ioctl and related definitions,
> > they are up to date and have more chances to match the kernel's idea of
> > the ioct
On Thu, Jan 28, 2021 at 12:45:09PM +0100, Roger Pau Monné wrote:
> On Tue, Jan 26, 2021 at 11:47:49PM +0100, Manuel Bouyer wrote:
> > When a domain is destroyed, xparams may not be available any more when
> > the block script is called to unconfigure the vnd.
> > Check xparam only at configure time
Hi Ian.
On 29.01.21 12:51, Oleksandr wrote:
On 29.01.21 10:49, Jan Beulich wrote:
Hi Jan
On 29.01.2021 09:13, Wei Chen wrote:
I just tested the v6 and the latest backend service with the latest
staging branch.
They work well.
Tested-by: Wei Chen
An faod this was again Arm-only testing
On 29.01.2021 11:45, Andrew Cooper wrote:
> ... in order to reuse stgi elsewhere.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 29.01.21 12:06, Jan Beulich wrote:
Hi Jan, Julien
On 29.01.2021 10:55, Julien Grall wrote:
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -137,7 +137,13 @@ config HYPFS_CONFIG
want to hide the .config contents from dom0.
config IOREQ_SERVER
- bool
+ boo
On 29.01.2021 12:19, Oleksandr wrote:
>
> On 29.01.21 12:06, Jan Beulich wrote:
>
> Hi Jan, Julien
>
>> On 29.01.2021 10:55, Julien Grall wrote:
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -137,7 +137,13 @@ config HYPFS_CONFIG
want to hide the .config co
On 29/01/2021 11:25, Jan Beulich wrote:
On 29.01.2021 12:19, Oleksandr wrote:
On 29.01.21 12:06, Jan Beulich wrote:
Hi Jan, Julien
On 29.01.2021 10:55, Julien Grall wrote:
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -137,7 +137,13 @@ config HYPFS_CONFIG
want to hide th
On 25.01.2021 18:59, Andrew Cooper wrote:
> On 20/01/2021 08:06, Jan Beulich wrote:
>> Also, as far as "impossible" here goes - the constructs all
>> anyway exist only to deal with what we consider impossible.
>> The question therefore really is of almost exclusively
>> theoretical nature, and henc
On 29.01.21 13:26, Julien Grall wrote:
Hi all
On 29/01/2021 11:25, Jan Beulich wrote:
On 29.01.2021 12:19, Oleksandr wrote:
On 29.01.21 12:06, Jan Beulich wrote:
Hi Jan, Julien
On 29.01.2021 10:55, Julien Grall wrote:
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -137,7 +137,1
Hi Andrew,
On 28/01/2021 16:06, Andrew Cooper wrote:
The ABI is unfortunate, and frame being 64 bits leads to all kinds of problems
performing correct overflow checks.
Furthermore, the mixed use of unsigned int and unsigned long in the call tree
is buggy on arm32 where the two are the same size
There are three noteworthy drawbacks:
1) The intercepts we need to enable here are CPL-independent, i.e. we
now have to emulate certain instructions for ring 0.
2) On VMX there's no intercept for SMSW, so the emulation isn't really
complete there.
3) The CR4 write intercept on SVM is lower pr
From: Norbert Kamiński
For now, this is simply enough logic to let Xen come up after the bootloader
has executed an SKINIT instruction to begin a Secure Startup.
During a Secure Startup, the BSP operates with the GIF clear (blocks all
external interrupts, even SMI/NMI), and INIT_REDIRECTION acti
On 29.01.2021 12:45, Jan Beulich wrote:
> There are three noteworthy drawbacks:
> 1) The intercepts we need to enable here are CPL-independent, i.e. we
>now have to emulate certain instructions for ring 0.
> 2) On VMX there's no intercept for SMSW, so the emulation isn't really
>complete th
Enable UMIP even if underlying hardware doesn't support it (assuming
the respective change supporting its emulation is in place). Obviously,
as explained in that patch, the SMSW test is then expected to fail on
Intel hardware.
Signed-off-by: Jan Beulich
--- a/tests/umip/Makefile
+++ b/tests/umip
On 29.01.2021 12:45, Andrew Cooper wrote:
> From: Norbert Kamiński
>
> For now, this is simply enough logic to let Xen come up after the bootloader
> has executed an SKINIT instruction to begin a Secure Startup.
>
> During a Secure Startup, the BSP operates with the GIF clear (blocks all
> exter
On 29.01.2021 12:37, Oleksandr wrote:
> I am wondering do we need to update support.md in the context of IOREQ
> status on Arm right now or this could be postponed?
I think so, yes. I have to admit I didn't even realize the whole
series doesn't make an addition there. I think this wants to be
par
On 29/01/2021 11:47, Jan Beulich wrote:
> Enable UMIP even if underlying hardware doesn't support it (assuming
> the respective change supporting its emulation is in place). Obviously,
> as explained in that patch, the SMSW test is then expected to fail on
> Intel hardware.
>
> Signed-off-by: Jan B
On 29.01.21 13:54, Jan Beulich wrote:
Hi Jan
On 29.01.2021 12:37, Oleksandr wrote:
I am wondering do we need to update support.md in the context of IOREQ
status on Arm right now or this could be postponed?
I think so, yes. I have to admit I didn't even realize the whole
series doesn't make
flight 158753 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158753/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
commit ef3a575baf53571dc405ee4028e26f50856898e7 upstream.
Allow issuing an IOCTL_PRIVCMD_MMAP_RESOURCE ioctl with num = 0 and
addr = 0 in order to fetch the size of a specific resource.
Add a shortcut to the default map resource path, since fetching the
size requires no address to be passed in, a
On Tue, Jan 12, 2021 at 04:17:27AM +, Igor Druzhinin wrote:
> TLFS 7.8.1 stipulates that "a virtual processor index must be less than
> the maximum number of virtual processors per partition" that "can be obtained
> through CPUID leaf 0x4005". Furthermore, "Requirements for Implementing
> t
On Tue, Jan 12, 2021 at 04:17:28AM +, Igor Druzhinin wrote:
> If Viridian extensions are enabled, Windows wouldn't currently allow
> a hotplugged vCPU to be brought up dynamically. We need to expose a special
> bit to let the guest know we allow it. Hide it behind an option to stay
> on the saf
On 29.01.2021 13:06, Oleksandr wrote:
> On 29.01.21 13:54, Jan Beulich wrote:
>> On 29.01.2021 12:37, Oleksandr wrote:
>>> I am wondering do we need to update support.md in the context of IOREQ
>>> status on Arm right now or this could be postponed?
>> I think so, yes. I have to admit I didn't even
flight 158773 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158773/
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
To prevent leaking HVM params via L1TF and similar issues on a
hyperthread pair, let's load values of domains as late as possible.
Furthermore, speculative barriers are re-arranged to make sure we do not
allow guests running on co-located VCPUs to leak hvm parameter values of
other domains.
This
On Fri, Jan 29, 2021 at 12:26 AM Jürgen Groß wrote:
>
> On 29.01.21 01:51, Marek Marczykowski-Górecki wrote:
> > On Thu, Jan 28, 2021 at 07:03:00PM -0500, Boris Ostrovsky wrote:
> >>
> >> On 1/28/21 6:52 PM, Michael D Labriola wrote:
> >>> Hey, everyone. I've run into problems starting up my Xen
On 29.01.21 15:13, Michael Labriola wrote:
On Fri, Jan 29, 2021 at 12:26 AM Jürgen Groß wrote:
On 29.01.21 01:51, Marek Marczykowski-Górecki wrote:
On Thu, Jan 28, 2021 at 07:03:00PM -0500, Boris Ostrovsky wrote:
On 1/28/21 6:52 PM, Michael D Labriola wrote:
Hey, everyone. I've run into p
Hi Rahul,
> On 29 Jan 2021, at 10:47, Rahul Singh wrote:
>
> SMMUv3 driver does not support ACPI device probe.If APCI is enabled with
> SMMUv3 driver compiler will throw an error.
>
> Disable SMMUv3 driver when ACPI is enabled in kconfig to fix compilation
> error.
>
> Signed-off-by: Rahul Sin
On 28.01.2021 14:08, Claudemir Todo Bom wrote:
> Em qui., 28 de jan. de 2021 às 06:49, Jan Beulich
> escreveu:
>>
>> On 28.01.2021 10:47, Jan Beulich wrote:
>>> On 26.01.2021 14:03, Claudemir Todo Bom wrote:
If this information is good for more tests, please send the patch and
I will te
Hi. Thanks for this.
Norbert Manthey writes ("[PATCH HVM v1 1/1] hvm: refactor set param"):
> To prevent leaking HVM params via L1TF and similar issues on a
> hyperthread pair, let's load values of domains as late as possible.
>
> Furthermore, speculative barriers are re-arranged to make sure we
On Fri, Jan 29, 2021 at 11:46:53AM +0100, Manuel Bouyer wrote:
> On Thu, Jan 28, 2021 at 12:08:02PM +0100, Roger Pau Monné wrote:
> > On Tue, Jan 26, 2021 at 11:47:58PM +0100, Manuel Bouyer wrote:
> > > Pass bridge name to qemu as command line option
> > > When starting qemu, set an environnement v
Roger Pau Monné writes ("Re: [PATCH] x86/pvh: pass module command line to
dom0"):
> On Fri, Jan 29, 2021 at 10:26:31AM +0100, Jan Beulich wrote:
> > On 29.01.2021 10:05, Roger Pau Monne wrote:
> > > Both the multiboot and the HVM start info structures allow passing a
> > > string together with a m
On Fri, Jan 29, 2021 at 11:38:43AM +0100, Manuel Bouyer wrote:
> On Thu, Jan 28, 2021 at 12:01:52PM +, Andrew Cooper wrote:
> > With the Xen side of this interface (soon to be) fixed to return real sizes,
> > userspace needs to be able to make the query.
> >
> > Introduce xenforeignmemory_reso
flight 158757 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158757/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c6be6dab9c4bdf135bc02b61ecc304d5511c3588
baseline version:
ovmf 2d6fc9d36fd5ff15972be
Em sex., 29 de jan. de 2021 às 11:21, Jan Beulich escreveu:
>
> On 28.01.2021 14:08, Claudemir Todo Bom wrote:
> > Em qui., 28 de jan. de 2021 às 06:49, Jan Beulich
> > escreveu:
> >>
> >> On 28.01.2021 10:47, Jan Beulich wrote:
> >>> On 26.01.2021 14:03, Claudemir Todo Bom wrote:
> If this
On 29/01/2021 14:59, Roger Pau Monné wrote:
> On Fri, Jan 29, 2021 at 11:38:43AM +0100, Manuel Bouyer wrote:
>> On Thu, Jan 28, 2021 at 12:01:52PM +, Andrew Cooper wrote:
>>> With the Xen side of this interface (soon to be) fixed to return real sizes,
>>> userspace needs to be able to make the
On 29/01/2021 14:19, Bertrand Marquis wrote:
Hi Rahul,
On 29 Jan 2021, at 10:47, Rahul Singh wrote:
SMMUv3 driver does not support ACPI device probe.If APCI is enabled with
SMMUv3 driver compiler will throw an error.
Disable SMMUv3 driver when ACPI is enabled in kconfig to fix compilation
On Thu, 2021-01-28 at 19:03 -0500, Boris Ostrovsky wrote:
> > I'm using Xen 4.13.1 on the box I've been testing with.
> >
> > I bisected down to this commit, and reverting it does indeed fix my
> > problem. Well, this commit upstream and it's cherry-picked variants
> > on linux-5.4.y and linux-5.
flight 158755 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158755/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 158719
test-amd64-amd64-xl-qemuu-ws16-amd64
On Fri, Jan 29, 2021 at 03:09:30PM +, Andrew Cooper wrote:
> On 29/01/2021 14:59, Roger Pau Monné wrote:
> > On Fri, Jan 29, 2021 at 11:38:43AM +0100, Manuel Bouyer wrote:
> >> On Thu, Jan 28, 2021 at 12:01:52PM +, Andrew Cooper wrote:
> >>> With the Xen side of this interface (soon to be)
Hi Oleksandr,
On 29/01/2021 11:06, Oleksandr wrote:
On 29.01.21 12:51, Oleksandr wrote:
On 29.01.21 10:49, Jan Beulich wrote:
Hi Jan
On 29.01.2021 09:13, Wei Chen wrote:
I just tested the v6 and the latest backend service with the latest
staging branch.
They work well.
Tested-by: Wei Che
On 29/01/2021 15:12, Julien Grall wrote:
On 29/01/2021 14:19, Bertrand Marquis wrote:
Hi Rahul,
On 29 Jan 2021, at 10:47, Rahul Singh wrote:
SMMUv3 driver does not support ACPI device probe.If APCI is enabled with
SMMUv3 driver compiler will throw an error.
Disable SMMUv3 driver when A
On 29/01/2021 11:29, Jan Beulich wrote:
> On 25.01.2021 18:59, Andrew Cooper wrote:
>> On 20/01/2021 08:06, Jan Beulich wrote:
>>> Also, as far as "impossible" here goes - the constructs all
>>> anyway exist only to deal with what we consider impossible.
>>> The question therefore really is of almo
The 2nd patch (RFC for now) is meant to address a regression
reported on the list under "Problems with APIC on versions 4.9
and later (4.8 works)". In the course of analyzing output from
a debugging patch I ran into another anomaly again, which I
thought I should finally try to address. Hence patch
Setting the timer a second (EPOCH) into the future at a random point
during boot (prior to bringing up APs and prior to launching Dom0) does
not yield predictable results: The timer may expire while we're still
bringing up APs (too early) or when Dom0 already boots (too late).
Instead invoke the ti
While doing this for small amounts may be okay, the unconditional use
of CPU0's value here has been found to be a problem when the boot time
TSC of the BSP was behind that of all APs by more than a second. In
particular because of get_s_time_fixed() producing insane output when
the calculated delta
On 29.01.21 18:06, Julien Grall wrote:
Hi Oleksandr,
Hi Julien, Ian
On 29/01/2021 11:06, Oleksandr wrote:
On 29.01.21 12:51, Oleksandr wrote:
On 29.01.21 10:49, Jan Beulich wrote:
Hi Jan
On 29.01.2021 09:13, Wei Chen wrote:
I just tested the v6 and the latest backend service with t
On 28.01.2021 14:08, Claudemir Todo Bom wrote:
> Em qui., 28 de jan. de 2021 às 06:49, Jan Beulich
> escreveu:
>>
>> On 28.01.2021 10:47, Jan Beulich wrote:
>>> On 26.01.2021 14:03, Claudemir Todo Bom wrote:
If this information is good for more tests, please send the patch and
I will te
On 29.01.2021 17:17, Andrew Cooper wrote:
> On 29/01/2021 11:29, Jan Beulich wrote:
>> On 25.01.2021 18:59, Andrew Cooper wrote:
>>> On 20/01/2021 08:06, Jan Beulich wrote:
Also, as far as "impossible" here goes - the constructs all
anyway exist only to deal with what we consider impossib
1 - 100 of 159 matches
Mail list logo
