On 22.02.2021 22:19, Boris Ostrovsky wrote:
>
> On 2/22/21 6:08 AM, Roger Pau Monné wrote:
>> On Fri, Feb 19, 2021 at 09:56:32AM -0500, Boris Ostrovsky wrote:
>>> On 2/18/21 5:51 AM, Roger Pau Monné wrote:
On Wed, Jan 20, 2021 at 05:49:10PM -0500, Boris Ostrovsky wrote:
> When toolstack u
On 22.02.2021 17:36, Andrew Cooper wrote:
> On 19/02/2021 08:09, Jan Beulich wrote:
>> --- a/xen/arch/x86/Makefile
>> +++ b/xen/arch/x86/Makefile
>> @@ -123,8 +123,13 @@ ifneq ($(efi-y),)
>> # Check if the compiler supports the MS ABI.
>> export XEN_BUILD_EFI := $(shell $(CC) $(XEN_CFLAGS) -c efi
flight 159559 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159559/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 8 xen-boot fail REGR. vs. 159475
test-amd64-i386-xl
On 23.02.2021 00:05, Stefano Stabellini wrote:
> On Fri, 19 Feb 2021, Jan Beulich wrote:
>> On 19.02.2021 02:42, Stefano Stabellini wrote:
>>> --- a/tools/configure.ac
>>> +++ b/tools/configure.ac
>>> @@ -307,6 +307,10 @@ AC_ARG_VAR([AWK], [Path to awk tool])
>>>
>>> # Checks for programs.
>>>
On 22.02.2021 19:04, Bobby Eshleman wrote:
> I just wanted to request more feedback on this series and put it on the
> radar, while acknowledging
> that I'm sure given the recent code freeze it is a busy time for everybody.
It is on my list of things to look at. While probably not a good excuse,
On 22.02.2021 17:47, Andrew Cooper wrote:
> On 22/02/2021 14:22, Jan Beulich wrote:
>> On 22.02.2021 15:14, Andrew Cooper wrote:
>>> On 22/02/2021 10:27, Jan Beulich wrote:
Now that we guard the entire Xen VA space against speculative abuse
through hypervisor accesses to guest memory, the
On 22.02.2021 21:12, Julien Grall wrote:
> On 22/02/2021 20:09, Stefano Stabellini wrote:
>> On Mon, 22 Feb 2021, Jan Beulich wrote:
>>> On 20.02.2021 20:47, Julien Grall wrote:
This is a follow-up of the discussion that started in 2019 (see [1])
regarding a possible race between do_poll(
2021年2月22日(月) 19:57 Gerd Hoffmann :
>
> On Sun, Feb 21, 2021 at 10:34:14PM +0900, Akihiko Odaki wrote:
> > This change introduces an additional member, refresh_rate to
> > qemu_edid_info in include/hw/display/edid.h.
> >
> > This change also isolates the graphics update interval from the
> > displa
On Mon, Feb 22, 2021 at 06:50:44PM +0100, Cornelia Huck wrote:
> On Mon, 22 Feb 2021 18:41:07 +0100
> Philippe Mathieu-Daudé wrote:
>
> > On 2/22/21 6:24 PM, Cornelia Huck wrote:
> > > On Fri, 19 Feb 2021 18:38:37 +0100
> > > Philippe Mathieu-Daudé wrote:
> > >
> > >> MachineClass::kvm_type()
On Tue, Feb 23, 2021 at 10:33:55AM +1100, David Gibson wrote:
> On Mon, Feb 22, 2021 at 06:50:44PM +0100, Cornelia Huck wrote:
> > On Mon, 22 Feb 2021 18:41:07 +0100
> > Philippe Mathieu-Daudé wrote:
> >
> > > On 2/22/21 6:24 PM, Cornelia Huck wrote:
> > > > On Fri, 19 Feb 2021 18:38:37 +0100
> >
Now we can try to preempt code that is running in hypervisor code. To
do so we need to try to invoke scheduler by calling try_preempt(),
while not in nested IRQ handler.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/traps.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/arch/
This code moves spin_unlock() and rcu_unlock_domain() earlier in the
code just to decrease time we spent with preemption disabled. Proper
fix is to replace spinlocks with mutexes, but mutexes are not
implemented yet.
With this patch enabled, allocation huge number of pages (e.g. 1GB of
RAM) does n
In the subsequent patches we will enable preemption in the hypervisor
mode. But we don't want any preemption attempts while system is
still not ready to call scheduler. So we should disable preemption
during early boot stages and enable it only when we switched to idle
vCPU stack.
Signed-off-by: V
With upcoming full hypervisor preemption it is possible that context
switching code will be called with IRQs already disabled. In this case
we don't want to enable them back. So we need to add logic that tracks
if IRQs are already disabled.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/domai
ASSERT_NOT_IN_ATOMIC() is very strict, because it checks that
local IRQs are disabled. But there is a case when this is okay:
when we finished handling IRQ in hypervisor mode we might want
to preempt current vCPU. In this case scheduler will be called
with local IRQs disabled.
On other hand, we wa
This function can be used to preempt code running in hypervisor mode.
Generally, there are two reasons to preempt while in HYP mode:
1. IRQ arrived. This may woke vCPU with higher scheduling priority.
2. Exit from atomic context. While we were in atomic context, state
of the system may changed
With XEN preemption enabled, scheduler functions can be called with
IRQs disabled (for example, at end of IRQ handler), so we should
save and restore IRQ state in schedulers code.
Signed-off-by: Volodymyr Babchuk
---
xen/common/sched/rt.c | 10 ++
1 file changed, 6 insertions(+), 4 delet
This ensures that preempt_count will be accounted correctly
during in-hypevisor context switches.
Signed-off-by: Volodymyr Babchuk
---
xen/common/preempt.c | 6 +++---
xen/include/xen/preempt.h | 9 -
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/xen/common/preempt.
With XEN preemption enabled, scheduler functions can be called with
IRQs disabled (for example, at end of IRQ handler), so we should
save and restore IRQ state in schedulers code.
Signed-off-by: Volodymyr Babchuk
---
xen/common/sched/credit2.c | 5 +++--
1 file changed, 3 insertions(+), 2 deleti
Hello community,
Subject of this cover letter is quite self-explanatory. This patch
series implements PoC for preemption in hypervisor mode.
This is the sort of follow-up to recent discussion about latency
([1]).
Motivation
==
It is well known that Xen is not preemptable. On other words
With XEN preemption enabled, scheduler functions can be called with
IRQs disabled (for example, at end of IRQ handler), so we should
save and restore IRQ state in schedulers code.
Signed-off-by: Volodymyr Babchuk
---
xen/common/sched/core.c | 33 ++---
1 file changed,
On Mon, 22 Feb 2021, Bertrand Marquis wrote:
> Hi Julien,
>
> > On 20 Feb 2021, at 14:04, Julien Grall wrote:
> >
> > From: Julien Grall
> >
> > Currently, Xen will send a data abort to a guest trying to write to the
> > ISPENDR.
> >
> > Unfortunately, recent version of Linux (at least 5.9+)
On Mon, 22 Feb 2021, Julien Grall wrote:
> On 22/02/2021 20:35, Stefano Stabellini wrote:
> > On Mon, 22 Feb 2021, Julien Grall wrote:
> > > On 22/02/2021 11:58, Bertrand Marquis wrote:
> > > > Hi Julien,
> > > >
> > > > > On 20 Feb 2021, at 17:54, Julien Grall wrote:
> > > > >
> > > > > From: J
On Mon, 22 Feb 2021, Julien Grall wrote:
> On 22/02/2021 20:09, Stefano Stabellini wrote:
> > On Mon, 22 Feb 2021, Jan Beulich wrote:
> > > On 20.02.2021 20:47, Julien Grall wrote:
> > > > From: Julien Grall
> > > >
> > > > The comment in vcpu_block() states that the events should be checked
> >
On Fri, 19 Feb 2021, Konrad Rzeszutek Wilk wrote:
> On Sun, Feb 07, 2021 at 04:56:01PM +0100, Christoph Hellwig wrote:
> > On Thu, Feb 04, 2021 at 09:40:23AM +0100, Christoph Hellwig wrote:
> > > So one thing that has been on my mind for a while: I'd really like
> > > to kill the separate dma ops
flight 159550 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159550/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-seattle broken
test-amd64-i386-xl-xsm7 xen-instal
On 22/02/2021 18:52, Kevin Negy wrote:
> Hello again,
>
> Thank you for the helpful responses. I have several follow up questions.
>
> 1)
>
> With Shadow, Xen has to do the combination of address spaces itself -
> the shadow pagetables map guest virtual to host physical address.
>
>
> T
flight 159545 qemu-mainline real [real]
flight 159562 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159545/
http://logs.test-lab.xenproject.org/osstest/logs/159562/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Fri, 19 Feb 2021, Jan Beulich wrote:
> On 19.02.2021 02:42, Stefano Stabellini wrote:
> > OK it took me a lot longer than expected (I have never had the dubious
> > pleasure of working with autoconf before) but the following seems to
> > work, tested on both Alpine Linux and Debian Unstable. Of
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-debianhvm-amd64
testid xen-boot
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git:/
On 2/22/21 6:08 AM, Roger Pau Monné wrote:
> On Fri, Feb 19, 2021 at 09:56:32AM -0500, Boris Ostrovsky wrote:
>> On 2/18/21 5:51 AM, Roger Pau Monné wrote:
>>> On Wed, Jan 20, 2021 at 05:49:10PM -0500, Boris Ostrovsky wrote:
When toolstack updates MSR policy, this MSR offset (which is the la
On 22/02/2021 20:35, Stefano Stabellini wrote:
On Mon, 22 Feb 2021, Julien Grall wrote:
On 22/02/2021 11:58, Bertrand Marquis wrote:
Hi Julien,
On 20 Feb 2021, at 17:54, Julien Grall wrote:
From: Julien Grall
At the moment, flush_page_to_ram() is both cleaning and invalidate to
PoC the
On Mon, 22 Feb 2021, Julien Grall wrote:
> On 22/02/2021 11:58, Bertrand Marquis wrote:
> > Hi Julien,
> >
> > > On 20 Feb 2021, at 17:54, Julien Grall wrote:
> > >
> > > From: Julien Grall
> > >
> > > At the moment, flush_page_to_ram() is both cleaning and invalidate to
> > > PoC the page. Ho
On 22/02/2021 20:09, Stefano Stabellini wrote:
On Mon, 22 Feb 2021, Jan Beulich wrote:
On 20.02.2021 20:47, Julien Grall wrote:
From: Julien Grall
The comment in vcpu_block() states that the events should be checked
/after/ blocking to avoids wakeup waiting race. However, from a generic
pe
flight 159540 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159540/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 8 xen-boot fail REGR. vs. 159475
test-amd64-i386-xl
On Mon, 22 Feb 2021, Jan Beulich wrote:
> On 20.02.2021 20:47, Julien Grall wrote:
> > From: Julien Grall
> >
> > The comment in vcpu_block() states that the events should be checked
> > /after/ blocking to avoids wakeup waiting race. However, from a generic
> > perspective, set_bit() doesn't pre
On Fri, 19 Feb 2021, Philippe Mathieu-Daudé wrote:
Restrit KVM to the following ARM machines:
Typo: "Restrict" (also in patch title).
Regards,
BALATON Zoltan
- virt
- xlnx-versal-virt
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/virt.c | 5 +
hw/arm/xlnx-versal-virt.c |
On Mon, Feb 22, 2021 at 04:47:38PM +, Andrew Cooper wrote:
> On 22/02/2021 14:22, Jan Beulich wrote:
> > On 22.02.2021 15:14, Andrew Cooper wrote:
> >> On 22/02/2021 10:27, Jan Beulich wrote:
> >>> Now that we guard the entire Xen VA space against speculative abuse
> >>> through hypervisor acce
On 2/5/21 2:12 PM, Daniel P. Smith wrote:
> Greetings,
>
> Per the community call on Feb. 4 I would like to get the working group
> started that will be reviewing the major design decisions for the DomB
> implementation. A summary of the discussion around the two primary
> decisions we are seeking
Hello again,
Thank you for the helpful responses. I have several follow up questions.
1)
> With Shadow, Xen has to do the combination of address spaces itself -
> the shadow pagetables map guest virtual to host physical address.
The shadow_blow_tables() call is "please recycle everything" whic
Andrew Cooper writes ("Re: Stable ABI checking (take 2)"):
> It turns out that libxl causes abi-dumper to churn for ~4s or so, which
> isn't ideal. All the other libraries are in the noise.
I think that means making it part of "make check" or something.
> However, to fix problems pertaining to t
On 22/02/2021 17:21, Ian Jackson wrote:
> Jan Beulich writes ("Re: Stable ABI checking (take 2)"):
>> On 22.02.2021 15:03, Andrew Cooper wrote:
>> +1 for option 2, fwiw.
> I'm in favour of option 2.
Option 2 it is then.
>
> Andrew Cooper writes ("Re: Stable ABI checking (take 2)"):
>> As far as R
Hey all,
I just wanted to request more feedback on this series and put it on the radar,
while acknowledging
that I'm sure given the recent code freeze it is a busy time for everybody.
Best,
Bob
On 2/22/21 6:50 PM, Cornelia Huck wrote:
> On Mon, 22 Feb 2021 18:41:07 +0100
> Philippe Mathieu-Daudé wrote:
>
>> On 2/22/21 6:24 PM, Cornelia Huck wrote:
>>> On Fri, 19 Feb 2021 18:38:37 +0100
>>> Philippe Mathieu-Daudé wrote:
>>>
MachineClass::kvm_type() can return -1 on failure.
On Mon, 22 Feb 2021 18:46:15 +0100
Philippe Mathieu-Daudé wrote:
> On 2/22/21 6:34 PM, Cornelia Huck wrote:
> > On Fri, 19 Feb 2021 18:38:38 +0100
> > Philippe Mathieu-Daudé wrote:
> >
> >> Introduce the valid_accelerators[] field to express the list
> >> of valid accelators a machine can use
On Mon, 22 Feb 2021 18:41:07 +0100
Philippe Mathieu-Daudé wrote:
> On 2/22/21 6:24 PM, Cornelia Huck wrote:
> > On Fri, 19 Feb 2021 18:38:37 +0100
> > Philippe Mathieu-Daudé wrote:
> >
> >> MachineClass::kvm_type() can return -1 on failure.
> >> Document it, and add a check in kvm_init().
> >
On Fri, 19 Feb 2021 18:38:47 +0100
Philippe Mathieu-Daudé wrote:
> Before configuring an accelerator, check it is valid for
> the current machine. Doing so we can return a simple error
> message instead of criptic one.
s/criptic/cryptic/
>
> Before:
>
> $ qemu-system-arm -M raspi2b -enable-
On 2/22/21 6:34 PM, Cornelia Huck wrote:
> On Fri, 19 Feb 2021 18:38:38 +0100
> Philippe Mathieu-Daudé wrote:
>
>> Introduce the valid_accelerators[] field to express the list
>> of valid accelators a machine can use, and add the
>> machine_class_valid_for_current_accelerator() and
>> machine_cla
On Fri, 19 Feb 2021 18:38:39 +0100
Philippe Mathieu-Daudé wrote:
> Do not let 'query-machines' return machines not valid with
> the current accelerator.
>
> Suggested-by: Daniel Berrangé
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/core/machine-qmp-cmds.c | 4
> 1 file changed, 4 i
On 2/22/21 6:24 PM, Cornelia Huck wrote:
> On Fri, 19 Feb 2021 18:38:37 +0100
> Philippe Mathieu-Daudé wrote:
>
>> MachineClass::kvm_type() can return -1 on failure.
>> Document it, and add a check in kvm_init().
>>
>> Signed-off-by: Philippe Mathieu-Daudé
>> ---
>> include/hw/boards.h | 3 ++-
On Fri, 19 Feb 2021 18:38:43 +0100
Philippe Mathieu-Daudé wrote:
I'd lose the 'Explicit' in $SUBJECT.
> All s390-ccw-virtio machines support TCG and KVM.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/s390x/s390-virtio-ccw.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git
On Fri, 19 Feb 2021 18:38:38 +0100
Philippe Mathieu-Daudé wrote:
> Introduce the valid_accelerators[] field to express the list
> of valid accelators a machine can use, and add the
> machine_class_valid_for_current_accelerator() and
> machine_class_valid_for_accelerator() methods.
>
> Signed-off
On Fri, 19 Feb 2021 18:38:37 +0100
Philippe Mathieu-Daudé wrote:
> MachineClass::kvm_type() can return -1 on failure.
> Document it, and add a check in kvm_init().
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/hw/boards.h | 3 ++-
> accel/kvm/kvm-all.c | 6 ++
> 2 files changed
Jan Beulich writes ("Re: Stable ABI checking (take 2)"):
> On 22.02.2021 15:03, Andrew Cooper wrote:
> +1 for option 2, fwiw.
I'm in favour of option 2.
Andrew Cooper writes ("Re: Stable ABI checking (take 2)"):
> As far as RPM is concerned, splitting the two is important, as %build
> and %check
Jan Beulich writes ("Re: [PATCH v3 1/2][4.15] VMX: delay p2m insertion of APIC
access page"):
> On 22.02.2021 12:25, Ian Jackson wrote:
> > Jan Beulich writes ("[PATCH v3 1/2][4.15] VMX: delay p2m insertion of APIC
> > access page"):
> >> Inserting the mapping at domain creation time leads to a m
On 22/02/2021 16:49, Jan Beulich wrote:
> On 22.02.2021 16:26, Andrew Cooper wrote:
>> At the moment, attempting to create an HVM guest with max_gnttab_frames of 0
>> causes Xen to explode on the:
>>
>> BUG_ON(atomic_read(&d->refcnt) != DOMAIN_DESTROYED);
>>
>> in _domain_destroy(). Intrumenting
flight 159546 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159546/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 078400ee15e7b250e4dfafd840c2e0c19835e16b
baseline version:
ovmf 44ae214591e58af468eac
On 22.02.2021 16:26, Andrew Cooper wrote:
> At the moment, attempting to create an HVM guest with max_gnttab_frames of 0
> causes Xen to explode on the:
>
> BUG_ON(atomic_read(&d->refcnt) != DOMAIN_DESTROYED);
>
> in _domain_destroy(). Intrumenting Xen a little more to highlight where the
> mo
On 22/02/2021 14:22, Jan Beulich wrote:
> On 22.02.2021 15:14, Andrew Cooper wrote:
>> On 22/02/2021 10:27, Jan Beulich wrote:
>>> Now that we guard the entire Xen VA space against speculative abuse
>>> through hypervisor accesses to guest memory, the argument translation
>>> area's VA also needs t
On 19/02/2021 08:09, Jan Beulich wrote:
> All of the sudden ld creates base relocations itself, for PE
> executables - as a result we now have two of them for every entity to
> be relocated. While we will likely want to use this down the road, it
> doesn't work quite right yet in corner cases, so r
On 22.02.2021 17:00, Andrew Cooper wrote:
> On 22/02/2021 14:37, Jan Beulich wrote:
>> On 22.02.2021 15:03, Andrew Cooper wrote:
>>> Hello,
>>>
>>> Staging is now capable of writing out an ABI description when the
>>> appropriate tool (abi-dumper) is available.
>>>
>>> We now have to possible cours
On Mon, Feb 22, 2021 at 04:50:14PM +0100, Jan Beulich wrote:
> Now that we guard the entire Xen VA space against speculative abuse
> through hypervisor accesses to guest memory, the argument translation
> area's VA also needs to live outside this range, at least for 32-bit PV
> guests. To avoid ext
On Mon, Feb 22, 2021 at 04:55:03PM +0100, Jan Beulich wrote:
> On 22.02.2021 16:31, Roger Pau Monné wrote:
> > On Wed, Feb 17, 2021 at 09:21:36AM +0100, Jan Beulich wrote:
> >> Using copy_{from,to}_user(), this code was assuming to be called only by
> >> PV guests. Use copy_{from,to}_guest() instea
On 22/02/2021 14:37, Jan Beulich wrote:
> On 22.02.2021 15:03, Andrew Cooper wrote:
>> Hello,
>>
>> Staging is now capable of writing out an ABI description when the
>> appropriate tool (abi-dumper) is available.
>>
>> We now have to possible courses of action for ABI checking in builds.
>>
>> 1) P
On 22.02.2021 16:31, Roger Pau Monné wrote:
> On Wed, Feb 17, 2021 at 09:21:36AM +0100, Jan Beulich wrote:
>> Using copy_{from,to}_user(), this code was assuming to be called only by
>> PV guests. Use copy_{from,to}_guest() instead, transforming the incoming
>> structure field into a guest handle (
Now that we guard the entire Xen VA space against speculative abuse
through hypervisor accesses to guest memory, the argument translation
area's VA also needs to live outside this range, at least for 32-bit PV
guests. To avoid extra is_hvm_*() conditionals, use the alternative VA
uniformly.
While
On Wed, Feb 17, 2021 at 09:21:36AM +0100, Jan Beulich wrote:
> Using copy_{from,to}_user(), this code was assuming to be called only by
> PV guests. Use copy_{from,to}_guest() instead, transforming the incoming
> structure field into a guest handle (the field should really have been
> one in the fi
At the moment, attempting to create an HVM guest with max_gnttab_frames of 0
causes Xen to explode on the:
BUG_ON(atomic_read(&d->refcnt) != DOMAIN_DESTROYED);
in _domain_destroy(). Intrumenting Xen a little more to highlight where the
modifcations to d->refcnt occur:
(d6) --- Xen Test Fram
On Wed, Feb 17, 2021 at 09:21:05AM +0100, Jan Beulich wrote:
> Bring them (back) in line with __{get,put}_guest().
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
>
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1649,19 +1649,19 @@ static void load_segments(struct
On Fri, Feb 19, 2021 at 03:39:14PM +0100, Jan Beulich wrote:
> On 10.02.2021 10:22, Roger Pau Monne wrote:
> > The for loop in unmap_domain_pirq is unnecessary complicated, with
> > several places where the index is incremented, and also different
> > exit conditions spread between the loop body.
>
On Fri, Feb 19, 2021 at 04:40:27PM +0100, Juergen Gross wrote:
> In order to support the possibility of per-device event channel
> settings (e.g. lateeoi spurious event thresholds) add a xenbus device
> pointer to struct irq_info() and modify the related event channel
> binding interfaces to take t
On Mon, Feb 22, 2021 at 03:20:24PM +0100, Jan Beulich wrote:
> On 22.02.2021 15:13, Roger Pau Monné wrote:
> > On Mon, Feb 22, 2021 at 12:35:21PM +0100, Roger Pau Monné wrote:
> >> On Mon, Feb 22, 2021 at 11:27:07AM +0100, Jan Beulich wrote:
> >>> Now that we guard the entire Xen VA space against s
On 22.02.2021 15:03, Andrew Cooper wrote:
> Hello,
>
> Staging is now capable of writing out an ABI description when the
> appropriate tool (abi-dumper) is available.
>
> We now have to possible courses of action for ABI checking in builds.
>
> 1) Publish the ABI descriptions on xenbits, update
Paolo, this series is fully reviewed, can it go via your
misc tree?
On 1/11/21 4:20 PM, Philippe Mathieu-Daudé wrote:
> Trivial prototype change to clarify the use of the 'running'
> argument of VMChangeStateHandler.
>
> Green CI:
> https://gitlab.com/philmd/qemu/-/pipelines/239497352
>
> Philip
On 20.02.2021 20:47, Julien Grall wrote:
> From: Julien Grall
>
> The comment in vcpu_block() states that the events should be checked
> /after/ blocking to avoids wakeup waiting race. However, from a generic
> perspective, set_bit() doesn't prevent re-ordering. So the following
> could happen:
>
On 22.02.2021 15:14, Andrew Cooper wrote:
> On 22/02/2021 10:27, Jan Beulich wrote:
>> Now that we guard the entire Xen VA space against speculative abuse
>> through hypervisor accesses to guest memory, the argument translation
>> area's VA also needs to live outside this range, at least for 32-bit
flight 159548 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159548/
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 22.02.2021 15:13, Roger Pau Monné wrote:
> On Mon, Feb 22, 2021 at 12:35:21PM +0100, Roger Pau Monné wrote:
>> On Mon, Feb 22, 2021 at 11:27:07AM +0100, Jan Beulich wrote:
>>> Now that we guard the entire Xen VA space against speculative abuse
>>> through hypervisor accesses to guest memory, the
The function drm_gem_fb_prepare_fb() is a helper for atomic modesetting,
but currently located next to framebuffer helpers. Move it to GEM atomic
helpers, rename it slightly and adopt the drivers. Same for the rsp
simple-pipe helper.
Compile-tested with x86-64, aarch64 and arm. The patch is fairly
On 22/02/2021 10:27, Jan Beulich wrote:
> Now that we guard the entire Xen VA space against speculative abuse
> through hypervisor accesses to guest memory, the argument translation
> area's VA also needs to live outside this range, at least for 32-bit PV
> guests. To avoid extra is_hvm_*() conditi
On Mon, Feb 22, 2021 at 12:35:21PM +0100, Roger Pau Monné wrote:
> On Mon, Feb 22, 2021 at 11:27:07AM +0100, Jan Beulich wrote:
> > Now that we guard the entire Xen VA space against speculative abuse
> > through hypervisor accesses to guest memory, the argument translation
> > area's VA also needs
On 22.02.2021 12:35, Roger Pau Monné wrote:
> On Mon, Feb 22, 2021 at 11:27:07AM +0100, Jan Beulich wrote:
>> Now that we guard the entire Xen VA space against speculative abuse
>> through hypervisor accesses to guest memory, the argument translation
>> area's VA also needs to live outside this ran
On 22.02.2021 12:25, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH v3 1/2][4.15] VMX: delay p2m insertion of APIC
> access page"):
>> Inserting the mapping at domain creation time leads to a memory leak
>> when the creation fails later on and the domain uses separate CPU and
>> IOMMU page table
Hello,
Staging is now capable of writing out an ABI description when the
appropriate tool (abi-dumper) is available.
We now have to possible courses of action for ABI checking in builds.
1) Publish the ABI descriptions on xenbits, update all downstream test
systems to invoke abi-compliance-check
Hi Julien,
> On 22 Feb 2021, at 13:37, Julien Grall wrote:
>
>
>
> On 22/02/2021 11:58, Bertrand Marquis wrote:
>> Hi Julien,
>>> On 20 Feb 2021, at 17:54, Julien Grall wrote:
>>>
>>> From: Julien Grall
>>>
>>> At the moment, flush_page_to_ram() is both cleaning and invalidate to
>>> PoC t
Hi Julien,
> On 20 Feb 2021, at 14:04, Julien Grall wrote:
>
> From: Julien Grall
>
> Currently, Xen will send a data abort to a guest trying to write to the
> ISPENDR.
>
> Unfortunately, recent version of Linux (at least 5.9+) will start
> writing to the register if the interrupt needs to be
On 22/02/2021 11:58, Bertrand Marquis wrote:
Hi Julien,
On 20 Feb 2021, at 17:54, Julien Grall wrote:
From: Julien Grall
At the moment, flush_page_to_ram() is both cleaning and invalidate to
PoC the page. However, the cache line can be speculated and pull in the
cache right after as it i
On 2/22/21 6:59 AM, David Gibson wrote:
> On Fri, Feb 19, 2021 at 06:38:42PM +0100, Philippe Mathieu-Daudé wrote:
>> Restrit KVM to the following PPC machines:
>> - 40p
>> - bamboo
>> - g3beige
>> - mac99
>> - mpc8544ds
>> - ppce500
>> - pseries
>> - sam460ex
>> - virtex-ml507
>
> Hrm.
>
> The re
On Mon, Feb 22, 2021 at 5:18 AM Roger Pau Monné wrote:
>
> On Fri, Feb 19, 2021 at 12:30:23PM -0500, Jason Andryuk wrote:
> > On Wed, Oct 21, 2020 at 9:59 AM Jan Beulich wrote:
> > >
> > > On 21.10.2020 15:36, Jason Andryuk wrote:
> > > > On Wed, Oct 21, 2020 at 8:53 AM Jan Beulich wrote:
> > >
flight 159533 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159533/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit2 broken
test-amd64-i386-xl-xsm7 xen-instal
On Mon, Feb 22, 2021 at 11:56:58AM +0100, Jan Beulich wrote:
> Inserting the mapping at domain creation time leads to a memory leak
> when the creation fails later on and the domain uses separate CPU and
> IOMMU page tables - the latter requires intermediate page tables to be
> allocated, but there
Hi Julien,
> On 20 Feb 2021, at 17:54, Julien Grall wrote:
>
> From: Julien Grall
>
> At the moment, flush_page_to_ram() is both cleaning and invalidate to
> PoC the page. However, the cache line can be speculated and pull in the
> cache right after as it is part of the direct map.
If we go f
On Mon, Feb 22, 2021 at 11:27:07AM +0100, Jan Beulich wrote:
> Now that we guard the entire Xen VA space against speculative abuse
> through hypervisor accesses to guest memory, the argument translation
> area's VA also needs to live outside this range, at least for 32-bit PV
> guests. To avoid ext
Jan Beulich writes ("[PATCH][4.15] x86: mirror compat argument translation area
for 32-bit PV"):
> Now that we guard the entire Xen VA space against speculative abuse
> through hypervisor accesses to guest memory, the argument translation
> area's VA also needs to live outside this range, at least
Jan Beulich writes ("[PATCH v3 1/2][4.15] VMX: delay p2m insertion of APIC
access page"):
> Inserting the mapping at domain creation time leads to a memory leak
> when the creation fails later on and the domain uses separate CPU and
> IOMMU page tables - the latter requires intermediate page table
Roger Pau Monné writes ("Re: [PATCH for-4.15 v2] VMX: use a single, global APIC
access page"):
> On Mon, Feb 22, 2021 at 08:51:59AM +0100, Jan Beulich wrote:
> > If anything, then the latter, but largely neither afaict - there's no
> > change in this regard here at all as far as the guest could af
Tamas K Lengyel writes ("[PATCH for-4.15] tools/misc/xen-vmtrace: use reset and
enable"):
> The expected behavior while using xen-vmtrace is to get a clean start, even if
> the tool was used previously on the same VM.
Release-Acked-by: Ian Jackson
Reviewed-by: Ian Jackson
and pushed to staging
Julien Grall writes ("[PATCH for-4.15] xen/sched: Add missing memory barrier in
vcpu_block()"):
> From: Julien Grall
>
> The comment in vcpu_block() states that the events should be checked
> /after/ blocking to avoids wakeup waiting race. However, from a generic
> perspective, set_bit() doesn't
Julien Grall writes ("[PATCH for-4.15] xen/vgic: Implement write to ISPENDR in
vGICv{2, 3}"):
> From: Julien Grall
>
> Currently, Xen will send a data abort to a guest trying to write to the
> ISPENDR.
>
> Unfortunately, recent version of Linux (at least 5.9+) will start
> writing to the regist
On Fri, Feb 19, 2021 at 09:56:32AM -0500, Boris Ostrovsky wrote:
>
> On 2/18/21 5:51 AM, Roger Pau Monné wrote:
> > On Wed, Jan 20, 2021 at 05:49:10PM -0500, Boris Ostrovsky wrote:
> >> When toolstack updates MSR policy, this MSR offset (which is the last
> >> index in the hypervisor MSR range) is
1 - 100 of 112 matches
Mail list logo
