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
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
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
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,
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
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
> >
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:
> > >
> > >>
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
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
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:
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
---
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
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
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
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
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
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
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:
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
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.
>
>
>
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
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
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
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
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.
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
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
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
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
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
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"
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
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
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
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
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
>>
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
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.
>
>
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
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
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(>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
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(>refcnt) != DOMAIN_DESTROYED);
>
> in _domain_destroy(). Intrumenting Xen a little more to highlight where the
>
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
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
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
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
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()
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)
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
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(>refcnt) != DOMAIN_DESTROYED);
in _domain_destroy(). Intrumenting Xen a little more to highlight where the
modifcations to d->refcnt occur:
(d6) --- Xen Test
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
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
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
>
>
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
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
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 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
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_*()
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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()
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
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)
1 - 100 of 112 matches
Mail list logo
