flight 159530 qemu-mainline real [real]
flight 159543 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159530/
http://logs.test-lab.xenproject.org/osstest/logs/159543/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Mon, Feb 22, 2021 at 08:51:59AM +0100, Jan Beulich wrote:
> On 19.02.2021 18:05, Ian Jackson wrote:
> > Jan Beulich writes ("Re: [PATCH v2] VMX: use a single, global APIC access
> > page"):
> >> While this patch was triggered not just by Julien's observation of
> >> the early p2m insertion bein
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:
> > >>
> > >> On 21.10.2020 14:45, Jason Andryuk wrote:
> > >>> On Wed, Oc
On Fri, Feb 19, 2021 at 09:50:12AM -0500, Boris Ostrovsky wrote:
>
> On 2/18/21 10:57 AM, Jan Beulich wrote:
> > On 18.02.2021 16:52, Roger Pau Monné wrote:
> >> On Thu, Feb 18, 2021 at 12:54:13PM +0100, Jan Beulich wrote:
> >>> On 18.02.2021 11:42, Roger Pau Monné wrote:
> Not that you need
> On Feb 22, 2021, at 7:51 AM, Jan Beulich wrote:
>
> On 19.02.2021 18:05, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [PATCH v2] VMX: use a single, global APIC access
>> page"):
>>> While this patch was triggered not just by Julien's observation of
>>> the early p2m insertion being a probl
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 22.02.2021 11:24, Roger Pau Monné wrote:
> On Fri, Feb 19, 2021 at 09:50:12AM -0500, Boris Ostrovsky wrote:
>>
>> On 2/18/21 10:57 AM, Jan Beulich wrote:
>>> On 18.02.2021 16:52, Roger Pau Monné wrote:
On Thu, Feb 18, 2021 at 12:54:13PM +0100, Jan Beulich wrote:
> On 18.02.2021 11:42, R
On 22.02.2021 11:26, George Dunlap wrote:
>
>
>> On Feb 22, 2021, at 7:51 AM, Jan Beulich wrote:
>>
>> On 19.02.2021 18:05, Ian Jackson wrote:
>>> Jan Beulich writes ("Re: [PATCH v2] VMX: use a single, global APIC access
>>> page"):
While this patch was triggered not just by Julien's obser
The latter of the two changes was on my mental todo list for a
very long time. With Julien reporting a problem with the handling
of this page, I finally felt urged to make a patch. As it turns
out, for addressing this problem only the first of the now split
pages is needed, and the second can be fu
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's no freeing of them at present in this case. Since
we don't need th
The address of this page is used by the CPU only to recognize when to
access the virtual APIC page instead. No accesses would ever go to this
page. It only needs to be present in the (CPU) page tables so that
address translation will produce its address as result for respective
accesses.
By making
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
> display update interval. The guest will update the fram
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
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
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
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
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
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
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
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
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: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
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 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:
> > >
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 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
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
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
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
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
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 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 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
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 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
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: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
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:
>
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 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
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 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 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 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
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: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
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 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 (
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 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 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 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 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 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 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
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: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
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
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
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
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: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 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: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: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: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 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 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 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.
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 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
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
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
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
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 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, 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
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 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
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: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 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
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 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
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 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 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 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
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 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, 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+)
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,
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
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
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 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 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
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
1 - 100 of 112 matches
Mail list logo
