flight 158118 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158118/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
One of the error paths in p2m_add_foreign could call put_page with a
NULL page, thus triggering a fault.
Split the checks into two different if statements, so the appropriate
error path can be taken.
Fixes: 173ae325026bd ('x86/p2m: tidy p2m_add_foreign() a little')
Signed-off-by: Roger Pau Monné
On Wed, 2020-12-23 at 12:10 -0800, Stefano Stabellini wrote:
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you can confirm the sender
> and know the content is safe.
>
>
>
> On Wed, 23 Dec 2020, Andrew Cooper wrote:
> > On 23/1
> -Original Message-
> From: Julien Grall
> Sent: 22 December 2020 15:44
> To: xen-devel@lists.xenproject.org
> Cc: hongy...@amazon.co.uk; Julien Grall ; Jan Beulich
> ; Paul
> Durrant
> Subject: [PATCH for-4.15 1/4] xen/iommu: Check if the IOMMU was initialized
> before tearing down
>
On Sun, Jan 03, 2021 at 02:04:53PM +0100, Philippe Mathieu-Daudé wrote:
> On 10/12/20 2:45 PM, Philippe Mathieu-Daudé wrote:
> > Trivial patches using the generic PCI macros from "hw/pci/pci.h".
> >
> > Philippe Mathieu-Daudé (5):
> > hw/pci-host/bonito: Make PCI_ADDR() macro more readable
>
On Wed, Dec 23, 2020 at 12:10:43PM -0800, Stefano Stabellini wrote:
> On Wed, 23 Dec 2020, Andrew Cooper wrote:
> > On 23/12/2020 19:45, Stefano Stabellini wrote:
> > > On Wed, 23 Dec 2020, no-re...@patchew.org wrote:
> > >> Hi,
> > >>
> > >> Patchew automatically ran gitlab-ci pipeline with this p
> -Original Message-
> From: Jan Beulich
> Sent: 23 December 2020 16:46
> To: Julien Grall ; Paul Durrant
> Cc: hongy...@amazon.co.uk; Julien Grall ;
> xen-devel@lists.xenproject.org
> Subject: Re: [PATCH for-4.15 3/4] [RFC] xen/iommu: x86: Clear the root
> page-table before freeing the
On Tue, Dec 29, 2020 at 12:29:09PM +0100, Roger Pau Monné wrote:
> I think you want tot CC the tools dev on this one, specially Ian who
> knows how the Linux one is implemented and can likely give valuable
> input.
>
> On Mon, Dec 14, 2020 at 05:36:04PM +0100, Manuel Bouyer wrote:
> > ---
> > too
On Tue, Dec 29, 2020 at 12:43:02PM +0100, Roger Pau Monné wrote:
> Maybe it would be easier to just fix libxl to always set the vifname
> in xenstore?
>
> FWIW, on FreeBSD I'm passing the vifname as an environment parameter
> to the script.
Actually I don't know why the vifname is not always set.
On Tue, Dec 29, 2020 at 12:46:38PM +0100, Roger Pau Monné wrote:
> What would happen when a new device (or ioctl to and existing one) is
> added?
>
> You would then run into issues of newer versions of Xen not building on
> older NetBSD systems, or would have to appropriately gate the newly
> adde
On Tue, Dec 29, 2020 at 12:52:43PM +0100, Roger Pau Monné wrote:
> On Mon, Dec 14, 2020 at 05:36:09PM +0100, Manuel Bouyer wrote:
> > ---
> > tools/libs/evtchn/netbsd.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/libs/evtchn/netbsd.c b/tools/libs/e
On Tue, Dec 29, 2020 at 12:16:01PM +0100, Roger Pau Monné wrote:
> Might need some kind of log message, and will also required your
> Signed-off-by (or from the original author of the patch).
>
> On Mon, Dec 14, 2020 at 05:36:11PM +0100, Manuel Bouyer wrote:
> > ---
> > tools/libs/gnttab/Makefile
On Tue, Dec 29, 2020 at 03:02:15PM +0100, Roger Pau Monné wrote:
> On Mon, Dec 14, 2020 at 05:36:12PM +0100, Manuel Bouyer wrote:
> > ---
> > tools/libs/light/libxl_create.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/libs/light/libxl_create.c
> >
On Tue, Dec 29, 2020 at 04:19:58PM +0100, Roger Pau Monné wrote:
> On Mon, Dec 14, 2020 at 05:36:13PM +0100, Manuel Bouyer wrote:
> > Pass bridge name to qemu
> > When starting qemu, set an environnement variable XEN_DOMAIN_ID,
> > to be used by qemu helper scripts
>
> NetBSD is the only one to us
On 04/01/2021 09:03, Roger Pau Monne wrote:
> One of the error paths in p2m_add_foreign could call put_page with a
> NULL page, thus triggering a fault.
>
> Split the checks into two different if statements, so the appropriate
> error path can be taken.
>
> Fixes: 173ae325026bd ('x86/p2m: tidy p2m_
On Tue, Dec 29, 2020 at 03:19:14PM +0100, Roger Pau Monné wrote:
> On Mon, Dec 14, 2020 at 05:36:15PM +0100, Manuel Bouyer wrote:
> > ---
> > tools/libs/light/libxl_netbsd.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tools/libs/light/libxl_netbsd.c
> > b/tools
flight 158115 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158115/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-xl-credit2 8 xen-boot fail in 158097 pass in 158115
test-amd64-amd64-xl-qemut-debian
On Mon, 2021-01-04 at 10:38 +0100, Roger Pau Monné wrote:
> On Wed, Dec 23, 2020 at 12:10:43PM -0800, Stefano Stabellini wrote:
> > On Wed, 23 Dec 2020, Andrew Cooper wrote:
> > > On 23/12/2020 19:45, Stefano Stabellini wrote:
> > > > On Wed, 23 Dec 2020, no-re...@patchew.org wrote:
> > > > > Hi,
>
On Tue, Dec 29, 2020 at 03:38:53PM +0100, Roger Pau Monné wrote:
> On Mon, Dec 14, 2020 at 05:36:18PM +0100, Manuel Bouyer wrote:
> > ---
> > tools/xenpaging/xenpaging.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/xenpaging/xenpaging.c b/tools/xenpagi
On Tue, Dec 29, 2020 at 03:51:55PM +0100, Roger Pau Monné wrote:
> I think it's dangerous to do this, specially on the stack, GNU libc
> manual states:
>
> Usage Note: Don?t use FILENAME_MAX as the size of an array in which to
> store a file name! You can?t possibly make an array that big! Use
> d
flight 158121 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158121/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 157875
build-amd64
On Tue, Dec 29, 2020 at 01:46:30PM +0100, Roger Pau Monné wrote:
> [...]
> > diff --git a/tools/libs/foreignmemory/private.h
> > b/tools/libs/foreignmemory/private.h
> > index 8f1bf081ed..abeceb8720 100644
> > --- a/tools/libs/foreignmemory/private.h
> > +++ b/tools/libs/foreignmemory/private.h
>
Update to v1.21.1 to fix build in Tumbleweed, which has been broken
since months due to lack of new release.
Signed-off-by: Olaf Hering
---
tools/firmware/etherboot/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/firmware/etherboot/Makefile
b/tools/firmware/et
On 03/01/2021 18:41, Tamas K Lengyel wrote:
> Required to introspect events originating from nested VMs.
>
> Signed-off-by: Tamas K Lengyel
> ---
> xen/arch/x86/hvm/monitor.c| 32 ++--
> xen/include/public/vm_event.h | 7 ++-
> 2 files changed, 36 insertions(+
On 03/01/2021 18:47, Tamas K Lengyel wrote:
> Running Xen compiled with UBSAN produces a warning for mismatched size. It's
> benign but this patch silences the warning.
>
> Signed-off-by: Tamas K Lengyel
> ---
> xen/arch/x86/mm/mem_sharing.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletio
On 03/01/2021 19:01, Tamas K Lengyel wrote:
> Add option to the monitor interface to disable walking of the guest pagetable
> on certain events. This is a performance optimization for tools that never
> require that information or prefer to do it themselves. For example LibVMI
> maintains a virtual
flight 158125 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158125/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0785c619a58a450091d2bf6755591012533b80b8
baseline version:
ovmf 140674a4601f804302e79
On 29.12.2020 11:56, Roger Pau Monné wrote:
> On Mon, Nov 23, 2020 at 01:39:55PM +0100, Jan Beulich wrote:
>> --- a/xen/arch/x86/acpi/boot.c
>> +++ b/xen/arch/x86/acpi/boot.c
>> @@ -422,8 +422,7 @@ acpi_fadt_parse_sleep_info(struct acpi_t
>> if (!facs_pa)
>> goto bad;
>>
>> -
On Thu, Dec 31, 2020 at 05:10:21PM +, Andrew Cooper wrote:
> nestedhap_walk_L1_p2m() takes guest physical addresses, not frame numbers.
> This means the l2 input is off-by-PAGE_SHIFT, as is the l1 value eventually
> returned to the caller.
>
> Delete the misleading comment as well.
>
> Fixes:
On Mon, Jan 4, 2021 at 8:04 AM Andrew Cooper wrote:
>
> On 03/01/2021 19:01, Tamas K Lengyel wrote:
> > Add option to the monitor interface to disable walking of the guest
> > pagetable
> > on certain events. This is a performance optimization for tools that never
> > require that information or
On Mon, Jan 4, 2021 at 6:57 AM Andrew Cooper wrote:
>
> On 03/01/2021 18:41, Tamas K Lengyel wrote:
> > Required to introspect events originating from nested VMs.
> >
> > Signed-off-by: Tamas K Lengyel
> > ---
> > xen/arch/x86/hvm/monitor.c| 32 ++--
> > xen/inclu
On Mon, Jan 04, 2021 at 11:56:14AM +0100, Manuel Bouyer wrote:
> On Tue, Dec 29, 2020 at 03:38:53PM +0100, Roger Pau Monné wrote:
> > On Mon, Dec 14, 2020 at 05:36:18PM +0100, Manuel Bouyer wrote:
> > > ---
> > > tools/xenpaging/xenpaging.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 delet
On 24.12.2020 10:57, Julien Grall wrote:
> Hi Jan,
>
> On 23/12/2020 15:13, Jan Beulich wrote:
>> This array can be large when many grant frames are permitted; avoid
>> allocating it when it's not going to be used anyway, by doing this only
>> in gnttab_populate_status_frames().
>>
>> Signed-off-b
On 28.12.2020 11:54, Roger Pau Monné wrote:
> On Mon, Nov 09, 2020 at 11:54:09AM +0100, Jan Beulich wrote:
>> Now that the IOMMU for guests can't be enabled "on demand" anymore,
>> there's also no reason to expose the related CPUID bit "just in case".
>>
>> Signed-off-by: Jan Beulich
>
> I'm not
On 28.12.2020 13:00, Roger Pau Monné wrote:
> On Wed, Nov 25, 2020 at 09:45:56AM +0100, Jan Beulich wrote:
>> This file has a long dependencies list (through asm-offsets.s) and a
>> long list of dependents. IOW if any of the former changes, all of the
>> latter will be rebuilt, even if there's no a
On 28.12.2020 13:54, Roger Pau Monné wrote:
> On Wed, Nov 25, 2020 at 09:49:21AM +0100, Jan Beulich wrote:
>> This file has a long dependencies list and asm-offsets.h, generated from
>> it, has a long list of dependents. IOW if any of the former changes, all
>> of the latter will be rebuilt, even i
On 28.12.2020 16:30, Roger Pau Monné wrote:
> On Wed, Nov 25, 2020 at 09:51:33AM +0100, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_64/compat/entry.S
>> +++ b/xen/arch/x86/x86_64/compat/entry.S
>> @@ -29,8 +29,6 @@ ENTRY(entry_int82)
>> mov %rsp, %rdi
>> call do_entry_int82
>>
On 29.12.2020 11:54, Roger Pau Monné wrote:
> On Wed, Dec 23, 2020 at 04:09:07PM +0100, Jan Beulich wrote:
>> On 30.11.2020 14:02, Jan Beulich wrote:
>>> On 24.11.2020 12:04, Jan Beulich wrote:
On 23.11.2020 17:14, Andrew Cooper wrote:
> On 23/11/2020 16:07, Roger Pau Monné wrote:
>> O
On 29.12.2020 11:51, Roger Pau Monné wrote:
> On Mon, Nov 23, 2020 at 01:40:12PM +0100, Jan Beulich wrote:
>> Use of __acpi_map_table() here was at least close to an abuse already
>> before, but it will now consistently return NULL here. Drop the layering
>> violation and use set_fixmap() directly.
On Tue, Dec 22, 2020 at 11:18:10PM -0600, Josh Poimboeuf wrote:
> For example, this scenario is allowed:
>
> Alt1Alt2Alt3
>
>0x00 CALL *pv_ops.save_flCALL xen_save_flPUSHF
>0x01
Current check for DM_OP availability in osdep_xendevicemodel_open will
always fail, because using DOMID_INVALID as the domain parameter will
make the hypervisor return -ESRCH, which will disable the usage of
the DOM_OP interface.
Fix this by checking the errno code of the test ioctl against
the pr
Hi Jan,
On 04/01/2021 13:37, Jan Beulich wrote:
On 24.12.2020 10:57, Julien Grall wrote:
Hi Jan,
On 23/12/2020 15:13, Jan Beulich wrote:
This array can be large when many grant frames are permitted; avoid
allocating it when it's not going to be used anyway, by doing this only
in gnttab_popula
flight 158123 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158123/
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 24.12.2020 16:24, Julien Grall wrote:
> From: Julien Grall
>
> Replace all the use of 1 << 31 with 1UL << 31 to prevent undefined
> behavior in the SMMU driver.
>
> Signed-off-by: Julien Grall
With, as already pointed out by Hans, 1UL replaced by 1U in
title and description
Reviewed-by: Jan
On 03.01.2021 07:40, Dylanger Daly wrote:
> Trying to debug Credit2
> https://wiki.xenproject.org/wiki/Credit2_Scheduler#Dumping_Status_and_Params
>
> It should be possible to get some debug output on what Credit2 is doing via
> pressing 'r' on the Serial Debug port
>
> Does anyone know if it's
flight 158116 qemu-mainline real [real]
flight 158129 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158116/
http://logs.test-lab.xenproject.org/osstest/logs/158129/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Hi Paul,
On 04/01/2021 09:28, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 22 December 2020 15:44
To: xen-devel@lists.xenproject.org
Cc: hongy...@amazon.co.uk; Julien Grall ; Jan Beulich
; Paul
Durrant
Subject: [PATCH for-4.15 1/4] xen/iommu: Check if the IOMMU was
On 04.01.2021 15:16, Julien Grall wrote:
> Hi Jan,
>
> On 04/01/2021 13:37, Jan Beulich wrote:
>> On 24.12.2020 10:57, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 23/12/2020 15:13, Jan Beulich wrote:
This array can be large when many grant frames are permitted; avoid
allocating it when it
On Mon, Jan 04, 2021 at 02:43:52PM +0100, Jan Beulich wrote:
> On 28.12.2020 11:54, Roger Pau Monné wrote:
> > On Mon, Nov 09, 2020 at 11:54:09AM +0100, Jan Beulich wrote:
> >> Now that the IOMMU for guests can't be enabled "on demand" anymore,
> >> there's also no reason to expose the related CPUI
On 04/01/2021 14:56, Roger Pau Monné wrote:
> On Mon, Jan 04, 2021 at 02:43:52PM +0100, Jan Beulich wrote:
>> On 28.12.2020 11:54, Roger Pau Monné wrote:
>>> On Mon, Nov 09, 2020 at 11:54:09AM +0100, Jan Beulich wrote:
Now that the IOMMU for guests can't be enabled "on demand" anymore,
th
On 23/12/2020 15:13, Jan Beulich wrote:
> This array can be large when many grant frames are permitted; avoid
> allocating it when it's not going to be used anyway, by doing this only
> in gnttab_populate_status_frames().
>
> Signed-off-by: Jan Beulich
> ---
> v2: Defer allocation to when a domain
On Mon, Jan 04, 2021 at 03:03:07PM +0100, Jan Beulich wrote:
> On 29.12.2020 11:54, Roger Pau Monné wrote:
> > My preference however would be for this to use vmap. Could the mapping
> > be established in acpi_fadt_parse_sleep_info instead of having to map
> > and unmap every time in acpi_sleep_prep
On 04.01.2021 15:56, Roger Pau Monné wrote:
> On Mon, Jan 04, 2021 at 02:43:52PM +0100, Jan Beulich wrote:
>> On 28.12.2020 11:54, Roger Pau Monné wrote:
>>> On Mon, Nov 09, 2020 at 11:54:09AM +0100, Jan Beulich wrote:
Now that the IOMMU for guests can't be enabled "on demand" anymore,
th
On Mon, Jan 04, 2021 at 03:09:52PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 22, 2020 at 11:18:10PM -0600, Josh Poimboeuf wrote:
>
> > For example, this scenario is allowed:
> >
> > Alt1Alt2Alt3
> >
> >0x00 CALL *pv_ops.save_flCALL xen
On 04.01.2021 16:04, Andrew Cooper wrote:
> On 23/12/2020 15:13, Jan Beulich wrote:
>> This array can be large when many grant frames are permitted; avoid
>> allocating it when it's not going to be used anyway, by doing this only
>> in gnttab_populate_status_frames().
>>
>> Signed-off-by: Jan Beuli
On 04/01/2021 15:22, Jan Beulich wrote:
> On 04.01.2021 16:04, Andrew Cooper wrote:
>> On 23/12/2020 15:13, Jan Beulich wrote:
>>> This array can be large when many grant frames are permitted; avoid
>>> allocating it when it's not going to be used anyway, by doing this only
>>> in gnttab_populate_s
On Mon, Jan 04, 2021 at 04:16:18PM +0100, Jan Beulich wrote:
> On 04.01.2021 15:56, Roger Pau Monné wrote:
> > On Mon, Jan 04, 2021 at 02:43:52PM +0100, Jan Beulich wrote:
> >> On 28.12.2020 11:54, Roger Pau Monné wrote:
> >>> On Mon, Nov 09, 2020 at 11:54:09AM +0100, Jan Beulich wrote:
> Now
On Mon, Jan 04, 2021 at 09:16:33AM -0600, Josh Poimboeuf wrote:
> > There's another fun scenario:
> >
> > 0x00 CALL *pv_ops.save_flPUSHF
> > 0x01 NOP2
> > ..
> > 0x03 NOP5
> > ..
> > 0x07 N
On Mon, Jan 04, 2021 at 02:56:12PM +0100, Jan Beulich wrote:
> On 28.12.2020 16:30, Roger Pau Monné wrote:
> > I would like to have Andrew's opinion on this one (as you and him tend
> > to modify more asm code than myself). There are quite a lot of
> > addition to the assembly code, and IMO it make
On 04.01.2021 16:41, Andrew Cooper wrote:
> On 04/01/2021 15:22, Jan Beulich wrote:
>> On 04.01.2021 16:04, Andrew Cooper wrote:
>>> On 23/12/2020 15:13, Jan Beulich wrote:
This array can be large when many grant frames are permitted; avoid
allocating it when it's not going to be used any
On 04.01.2021 16:45, Roger Pau Monné wrote:
> On Mon, Jan 04, 2021 at 04:16:18PM +0100, Jan Beulich wrote:
>> On 04.01.2021 15:56, Roger Pau Monné wrote:
>>> On Mon, Jan 04, 2021 at 02:43:52PM +0100, Jan Beulich wrote:
On 28.12.2020 11:54, Roger Pau Monné wrote:
> On Mon, Nov 09, 2020 at 1
On 04.01.2021 16:53, Roger Pau Monné wrote:
> On Mon, Jan 04, 2021 at 02:56:12PM +0100, Jan Beulich wrote:
>> On 28.12.2020 16:30, Roger Pau Monné wrote:
>>> I would like to have Andrew's opinion on this one (as you and him tend
>>> to modify more asm code than myself). There are quite a lot of
>>>
On 04.01.2021 14:28, Tamas K Lengyel wrote:
> On Mon, Jan 4, 2021 at 6:57 AM Andrew Cooper
> wrote:
>>
>> On 03/01/2021 18:41, Tamas K Lengyel wrote:
>>> Required to introspect events originating from nested VMs.
>>>
>>> Signed-off-by: Tamas K Lengyel
>>> ---
>>> xen/arch/x86/hvm/monitor.c|
flight 158119 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158119/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 14 guest-start fail REGR. vs. 152332
test-amd64-amd64-xl
On Mon, Jan 4, 2021 at 11:21 AM Jan Beulich wrote:
>
> On 04.01.2021 14:28, Tamas K Lengyel wrote:
> > On Mon, Jan 4, 2021 at 6:57 AM Andrew Cooper
> > wrote:
> >>
> >> On 03/01/2021 18:41, Tamas K Lengyel wrote:
> >>> Required to introspect events originating from nested VMs.
> >>>
> >>> Signed
On 28.12.2020 19:24, Roger Pau Monné wrote:
> On Mon, Dec 07, 2020 at 11:36:38AM +0100, Jan Beulich wrote:
>> None of the four reasons causing vpci_msix_arch_mask_entry() to get
>> called (there's just a single call site) are impossible or illegal prior
>> to an entry actually having got set up:
>>
On 12/24/20 6:53 AM, David Woodhouse wrote:
> From: David Woodhouse
>
> For a while, event channel notification via the PCI platform device
> has been broken, because we attempt to communicate with xenstore before
> we even have notifications working, with the xs_reset_watches() call
> in xs_ini
On 12/24/20 6:53 AM, David Woodhouse wrote:
> From: David Woodhouse
>
> With INTX or GSI delivery, Xen uses the event channel structures of CPU0.
>
> If the interrupt gets handled by Linux on a different CPU, then no events
> are seen as pending. Rather than introducing locking to allow other CP
On 12/24/20 6:53 AM, David Woodhouse wrote:
> From: David Woodhouse
>
> It's useful to be able to test non-vector event channel delivery, to make
> sure Linux will work properly on older Xen which doesn't have it.
>
> It's also useful for those working on Xen and Xen-compatible hypervisors,
> be
On 28.12.2020 18:58, Roger Pau Monné wrote:
> On Mon, Dec 07, 2020 at 11:38:42AM +0100, Jan Beulich wrote:
>> First of all introduce a local variable for the to be allocated struct.
>> The compiler can't CSE all the occurrences (I'm observing 80 bytes of
>> code saved with gcc 10). Additionally, wh
On 04/01/2021 16:32, Tamas K Lengyel wrote:
> On Mon, Jan 4, 2021 at 11:21 AM Jan Beulich wrote:
>> On 04.01.2021 14:28, Tamas K Lengyel wrote:
>>> On Mon, Jan 4, 2021 at 6:57 AM Andrew Cooper
>>> wrote:
On 03/01/2021 18:41, Tamas K Lengyel wrote:
> Required to introspect events origina
On 12/24/20 6:53 AM, David Woodhouse wrote:
> From: David Woodhouse
>
> In the case where xen_have_vector_callback is false, we still register
> the IPI vectors in xen_smp_intr_init() for the secondary CPUs even
> though they aren't going to be used. Stop doing that.
>
> Signed-off-by: David Woo
Hello all.
[Sorry for the possible format issues]
On Tue, Dec 22, 2020 at 12:41 PM Andrew Cooper
wrote:
> On 21/12/2020 08:10, Jan Beulich wrote:
> > On 17.12.2020 20:18, Andrew Cooper wrote:
> >> On 15/12/2020 16:26, Jan Beulich wrote:
> >>> This is together with its only caller, xenmem_add_to
On Mon, Jan 04, 2021 at 11:25:52AM +0100, Manuel Bouyer wrote:
> On Tue, Dec 29, 2020 at 12:46:38PM +0100, Roger Pau Monné wrote:
> > What would happen when a new device (or ioctl to and existing one) is
> > added?
> >
> > You would then run into issues of newer versions of Xen not building on
> >
On 12/24/20 6:53 AM, David Woodhouse wrote:
> From: David Woodhouse
>
> When xen_have_vector_callback is false, we still register the PV spinlock
> kicker IPI on the secondary CPUs. Stop doing that.
>
> Signed-off-by: David Woodhouse
> ---
> arch/x86/xen/spinlock.c | 6 +++---
> 1 file changed
On Mon, Jan 4, 2021 at 11:48 AM Andrew Cooper wrote:
>
> On 04/01/2021 16:32, Tamas K Lengyel wrote:
> > On Mon, Jan 4, 2021 at 11:21 AM Jan Beulich wrote:
> >> On 04.01.2021 14:28, Tamas K Lengyel wrote:
> >>> On Mon, Jan 4, 2021 at 6:57 AM Andrew Cooper
> >>> wrote:
> On 03/01/2021 18:41
On Mon, Jan 04, 2021 at 11:26:45AM +0100, Manuel Bouyer wrote:
> On Tue, Dec 29, 2020 at 12:52:43PM +0100, Roger Pau Monné wrote:
> > On Mon, Dec 14, 2020 at 05:36:09PM +0100, Manuel Bouyer wrote:
> > > ---
> > > tools/libs/evtchn/netbsd.c | 8
> > > 1 file changed, 4 insertions(+), 4 del
On Mon, Jan 04, 2021 at 06:09:07PM +0100, Roger Pau Monné wrote:
> We usually take a different approach for Linux and FreeBSD in
> order to support all kernels: test if the new ioctl is available, or
> else fallback to the old implementation. But this requires having the
> new header even on old sy
On Mon, Jan 4, 2021 at 7:31 AM Andrew Cooper wrote:
>
> On 03/01/2021 18:47, Tamas K Lengyel wrote:
> > Running Xen compiled with UBSAN produces a warning for mismatched size. It's
> > benign but this patch silences the warning.
> >
> > Signed-off-by: Tamas K Lengyel
> > ---
> > xen/arch/x86/mm/
On Mon, Jan 04, 2021 at 11:29:51AM +0100, Manuel Bouyer wrote:
> On Tue, Dec 29, 2020 at 12:16:01PM +0100, Roger Pau Monné wrote:
> > Might need some kind of log message, and will also required your
> > Signed-off-by (or from the original author of the patch).
> >
> > On Mon, Dec 14, 2020 at 05:36
On Mon, 2021-01-04 at 11:50 -0500, boris.ostrov...@oracle.com wrote:
> > diff --git a/arch/x86/xen/enlighten_hvm.c
> > b/arch/x86/xen/enlighten_hvm.c
> > index a1c07e0c888e..7a6ef517e81a 100644
> > --- a/arch/x86/xen/enlighten_hvm.c
> > +++ b/arch/x86/xen/enlighten_hvm.c
> > @@ -164,10 +164,10 @@ s
On Mon, 4 Jan 2021, Zheng, Fam wrote:
> On Mon, 2021-01-04 at 10:38 +0100, Roger Pau Monné wrote:
> > On Wed, Dec 23, 2020 at 12:10:43PM -0800, Stefano Stabellini wrote:
> > > On Wed, 23 Dec 2020, Andrew Cooper wrote:
> > > > On 23/12/2020 19:45, Stefano Stabellini wrote:
> > > > > On Wed, 23 Dec 2
On Mon, 2021-01-04 at 12:06 -0500, boris.ostrov...@oracle.com wrote:
> > @@ -115,7 +115,7 @@ PV_CALLEE_SAVE_REGS_THUNK(xen_vcpu_stolen);
> > void __init xen_init_spinlocks(void)
> > {
> >/* Don't need to use pvqspinlock code if there is only 1 vCPU. */
> > - if (num_possible_cpus()
On Mon, Jan 04, 2021 at 03:12:02PM +0100, Roger Pau Monne wrote:
> Current check for DM_OP availability in osdep_xendevicemodel_open will
> always fail, because using DOMID_INVALID as the domain parameter will
> make the hypervisor return -ESRCH, which will disable the usage of
> the DOM_OP interfa
On 04/01/2021 17:30, Stefano Stabellini wrote:
On Mon, 4 Jan 2021, Zheng, Fam wrote:
On Mon, 2021-01-04 at 10:38 +0100, Roger Pau Monné wrote:
On Wed, Dec 23, 2020 at 12:10:43PM -0800, Stefano Stabellini wrote:
On Wed, 23 Dec 2020, Andrew Cooper wrote:
On 23/12/2020 19:45, Stefano Stabelli
On 04/01/2021 17:30, Stefano Stabellini wrote:
> On Mon, 4 Jan 2021, Zheng, Fam wrote:
>> On Mon, 2021-01-04 at 10:38 +0100, Roger Pau Monné wrote:
>>> On Wed, Dec 23, 2020 at 12:10:43PM -0800, Stefano Stabellini wrote:
On Wed, 23 Dec 2020, Andrew Cooper wrote:
> On 23/12/2020 19:45, Stefa
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index c428fd16ce..4a02c7d6f2 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1764,6
Several lock-order violations have been encountered while attempting to fork
VMs with nestedhvm=1 set. This patch resolves the issues.
The order violations stems from a call to p2m_flush_nestedp2m being performed
whenever the hostp2m changes. This functions always takes the p2m lock for the
nested
On Thu, 24 Dec 2020, Julien Grall wrote:
> From: Julien Grall
>
> clang 11 will throw the following error while build Xen:
>
> scif-uart.c:333:33: error: cast to smaller integer type 'enum port_types'
> from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
> uart->params = &port_params[
flight 158134 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158134/
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 Mon, Jan 04, 2021 at 05:35:23PM +0100, Jan Beulich wrote:
> Thanks.
>
> > Manuel, can we get confirmation that this fixes your issue?
>
> I'll give it some time before committing for him to confirm,
> but I guess I'd like to time out by the end of the week.
Yes, it works for me
--
Manuel Bo
On Mon, 4 Jan 2021, Andrew Cooper wrote:
> On 04/01/2021 17:30, Stefano Stabellini wrote:
> > On Mon, 4 Jan 2021, Zheng, Fam wrote:
> >> On Mon, 2021-01-04 at 10:38 +0100, Roger Pau Monné wrote:
> >>> On Wed, Dec 23, 2020 at 12:10:43PM -0800, Stefano Stabellini wrote:
> On Wed, 23 Dec 2020, An
On Mon, Jan 04, 2021 at 11:31:56AM +0100, Manuel Bouyer wrote:
> On Tue, Dec 29, 2020 at 03:02:15PM +0100, Roger Pau Monné wrote:
> > On Mon, Dec 14, 2020 at 05:36:12PM +0100, Manuel Bouyer wrote:
> > > ---
> > > tools/libs/light/libxl_create.c | 8
> > > 1 file changed, 4 insertions(+),
On 02/01/2021 19:20, Charles Gonçalves wrote:
> Sure.
>
> The goal is to emulate a scenario where a compromised guest attacks
> another
> tenant in the same physical host reading/changing the memory content.
> E.g., extract the RSA key.
>
> I'll be in the domU kernel space. I'm assuming that th
On Mon, Jan 04, 2021 at 12:30:44PM +0100, Manuel Bouyer wrote:
> On Tue, Dec 29, 2020 at 01:46:30PM +0100, Roger Pau Monné wrote:
> > Also a little bit below these prototypes are the dummy implementations
> > of osdep_xenforeignmemory_restrict,
> > osdep_xenforeignmemory_map_resource and
> > osdep_
On 1/4/21 12:32 PM, David Woodhouse wrote:
> On Mon, 2021-01-04 at 12:06 -0500, boris.ostrov...@oracle.com wrote:
>>> @@ -115,7 +115,7 @@ PV_CALLEE_SAVE_REGS_THUNK(xen_vcpu_stolen);
>>> void __init xen_init_spinlocks(void)
>>> {
>>>/* Don't need to use pvqspinlock code if there is on
On Mon, 2021-01-04 at 14:06 -0500, boris.ostrov...@oracle.com wrote:
> On 1/4/21 12:32 PM, David Woodhouse wrote:
> > On Mon, 2021-01-04 at 12:06 -0500, boris.ostrov...@oracle.com wrote
> > :
> > > > @@ -115,7 +115,7 @@ PV_CALLEE_SAVE_REGS_THUNK(xen_vcpu_stolen);
> > > >void __init xen_init_spi
On 1/4/21 3:51 PM, David Woodhouse wrote:
> On Mon, 2021-01-04 at 14:06 -0500, boris.ostrov...@oracle.com wrote:
>>
>> OK, but we still need to do something about virt_spin_lock_key.
> Right, I suppose we should just call xen_init_spinlocks() and then my
> defensive check stops being defensive an
On Mon, 2021-01-04 at 17:09 -0500, boris.ostrov...@oracle.com wrote:
>
> I actually think this should go further in that only IPI-related ops
> should be conditioned on vector callback presence. The rest are
> generic VCPU routines that are not necessarily interrupt/event-
> related. And if they c
On Mon, Dec 21, 2020 at 06:28:35PM +, Julien Grall wrote:
> On 21/12/2020 17:30, Elliott Mitchell wrote:
> > I doubt this is the only bug exposed by
> > 5a37207df52066efefe419c677b089a654d37afc.
>
> Are you saying that with my patch dropped, Xen will boot but with it
> will not?
I thought th
1 - 100 of 129 matches
Mail list logo
