On 21.09.21 09:49, Juergen Gross wrote:
> On 21.09.21 08:38, Oleksandr Andrushchenko wrote:
>>
>> On 21.09.21 09:07, Juergen Gross wrote:
>>> On 21.09.21 07:51, Oleksandr Andrushchenko wrote:
On 21.09.21 08:20, Juergen Gross wrote:
> On 21.09.21 01:16, Stefano Stabellini wrote:
>
Disabling preemption in xen_irq_enable() is not needed. There is no
risk of missing events due to preemption, as preemption can happen
only in case an event is being received, which is just the opposite
of missing an event.
Signed-off-by: Juergen Gross
---
arch/x86/xen/irq.c | 18 +++
On 21.09.21 09:00, Oleksandr Andrushchenko wrote:
On 21.09.21 09:49, Juergen Gross wrote:
On 21.09.21 08:38, Oleksandr Andrushchenko wrote:
On 21.09.21 09:07, Juergen Gross wrote:
On 21.09.21 07:51, Oleksandr Andrushchenko wrote:
On 21.09.21 08:20, Juergen Gross wrote:
On 21.09.21 01:16,
In the course of fixing XSA-378 fallout I ran into a number of
issues, which this series is trying to deal with. The majority of
the changes is pretty much independent of one another.
There was another rather basic issue to fight first (patch
was submitted separately as RFC): vPCI wasn't aware of
Assuming that the accounting for IOMMU page tables will also take care
of the P2M needs was wrong: dom0_paging_pages() can determine a far
higher value, high enough for the system to run out of memory while
setting up Dom0. Hence in the case of shared page tables the larger of
the two values needs
On 21.09.21 10:09, Juergen Gross wrote:
> On 21.09.21 09:00, Oleksandr Andrushchenko wrote:
>>
>> On 21.09.21 09:49, Juergen Gross wrote:
>>> On 21.09.21 08:38, Oleksandr Andrushchenko wrote:
On 21.09.21 09:07, Juergen Gross wrote:
> On 21.09.21 07:51, Oleksandr Andrushchenko wrote:
Leaving shadow setup just to the L1TF tasklet means running Dom0 on a
minimally acceptable shadow memory pool, rather than what normally
would be used (also, for example, for PVH). Populate the pool before
triggering the tasklet, on a best effort basis (again like done for
PVH).
Signed-off-by: Jan
Certain notifications of Dom0 to Xen are independent of the mode Dom0 is
running in. Permit further PCI related ones (only their modern forms).
Also include the USB2 debug port operation at this occasion.
Signed-off-by: Jan Beulich
---
I'm uncertain about the has_vpci() part of the check: I would
Like PV Dom0 in order to use the console if in a mode other than text
80x25 the kernel needs to be provided information about this mode. Bump
HVM start info's "current" version to 2 and use a previously reserved
32-bit field to provide struct dom0_vga_console_info's position and
size.
Signed-off-b
vcpu_show_registers() didn't do anything for HVM so far. Note though
that some extra hackery is needed for VMX - see the code comment.
Note further that the show_guest_stack() invocation is left alone here:
While strictly speaking guest_kernel_mode() should be predicated by a
PV / !HVM check, show
While all present callers want to act on "current", stack dumping for
HVM vCPU-s will require the function to be able to act on a remote vCPU.
To avoid touching all present callers, convert the existing function to
an inline wrapper around the extend new one.
Signed-off-by: Jan Beulich
---
Altern
show_guest_stack() does nothing for HVM. Introduce a HVM-specific
dumping function, paralleling the 64- and 32-bit PV ones. We don't know
the real stack size, so only dump up to the next page boundary.
Rather than adding a vcpu parameter to hvm_copy_from_guest_linear(),
introduce hvm_copy_from_vcp
There's not really any register state associated with offline vCPU-s, so
avoid spamming the log with largely useless information while still
leaving an indication of the fact.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -242,6 +2
To become independent of the sequence of mapping operations, permit
"access" to accumulate for Dom0, noting that there's not going to be an
introspection agent for it which this might interfere with. While e.g.
ideally only ROM regions would get mapped with X set, getting there is
quite a bit of wo
On 26.08.2021 14:31, Jan Beulich wrote:
> On 26.08.2021 14:10, Andrew Cooper wrote:
>> On 26/08/2021 08:23, Jan Beulich wrote:
>>> While the specification doesn't say so, just like for VT-d's RMRRs no
>>> good can come from these ranges being e.g. conventional RAM or entirely
>>> unmarked and hence
On 20.09.21 18:15, Jan Beulich wrote:
The initial observation was that in PV mode under Xen 32-bit user space
didn't work anymore. Attempts of system calls ended in #GP(0x402). All
of the sudden the vector 0x80 handler was not in place anymore. As it
turns out up to 5.13 redundant initialization
On 21.09.2021 09:02, Juergen Gross wrote:
> --- a/arch/x86/xen/irq.c
> +++ b/arch/x86/xen/irq.c
> @@ -57,24 +57,20 @@ asmlinkage __visible void xen_irq_enable(void)
> {
> struct vcpu_info *vcpu;
>
> - /*
> - * We may be preempted as soon as vcpu->evtchn_upcall_mask is
> - * c
On 17.09.21 15:01, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Xen-pciback driver was designed to be built for x86 only. But it
can also be used by other architectures, e.g. Arm.
Re-structure the driver in a way that it can be built for other
platforms as well.
Signed-off-by:
Could you explicitly mention PV somewhere in the subject?
On Mon, Jun 28, 2021 at 01:52:52PM +0200, Jan Beulich wrote:
> If anything, a check covering a wider range of invalid M2P entries ought
> to be used (e.g. VALID_M2P()). But since everything is fully under Xen's
> control at this stage, simp
On Tue, Sep 21, 2021 at 08:10:12AM +0200, Jan Beulich wrote:
> On 06.07.2021 09:37, Jan Beulich wrote:
> > On 28.06.2021 13:52, Jan Beulich wrote:
> >> If anything, a check covering a wider range of invalid M2P entries ought
> >> to be used (e.g. VALID_M2P()). But since everything is fully under Xe
On 21.09.2021 09:55, Roger Pau Monné wrote:
> On Tue, Sep 21, 2021 at 08:10:12AM +0200, Jan Beulich wrote:
>> On 06.07.2021 09:37, Jan Beulich wrote:
>>> On 28.06.2021 13:52, Jan Beulich wrote:
If anything, a check covering a wider range of invalid M2P entries ought
to be used (e.g. VALID
On 21.09.21 09:53, Jan Beulich wrote:
On 21.09.2021 09:02, Juergen Gross wrote:
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -57,24 +57,20 @@ asmlinkage __visible void xen_irq_enable(void)
{
struct vcpu_info *vcpu;
- /*
-* We may be preempted as soon as vcpu->evtchn
On 21.09.21 10:54, Juergen Gross wrote:
> On 17.09.21 15:01, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Xen-pciback driver was designed to be built for x86 only. But it
>> can also be used by other architectures, e.g. Arm.
>> Re-structure the driver in a way that it can
On 01.09.2021 18:06, Jan Beulich wrote:
> The function may fail; it is not correct to indicate "success" in this
> case up the call stack. Mark the function must-check to prove all
> cases have been caught (and no new ones will get introduced).
>
> Signed-off-by: Jan Beulich
> ---
> In the grant-
On 21.09.2021 09:58, Juergen Gross wrote:
> On 21.09.21 09:53, Jan Beulich wrote:
>> On 21.09.2021 09:02, Juergen Gross wrote:
>>> --- a/arch/x86/xen/irq.c
>>> +++ b/arch/x86/xen/irq.c
>>> @@ -57,24 +57,20 @@ asmlinkage __visible void xen_irq_enable(void)
>>> {
>>> struct vcpu_info *vcpu;
>>>
On 21.09.21 10:11, Jan Beulich wrote:
On 21.09.2021 09:58, Juergen Gross wrote:
On 21.09.21 09:53, Jan Beulich wrote:
On 21.09.2021 09:02, Juergen Gross wrote:
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -57,24 +57,20 @@ asmlinkage __visible void xen_irq_enable(void)
{
stru
On Tue, Sep 21, 2021 at 09:02:26AM +0200, Juergen Gross wrote:
> Disabling preemption in xen_irq_enable() is not needed. There is no
> risk of missing events due to preemption, as preemption can happen
> only in case an event is being received, which is just the opposite
> of missing an event.
>
>
On Mon, Sep 20, 2021 at 05:27:17PM +0200, Jan Beulich wrote:
> On 20.09.2021 12:20, Roger Pau Monné wrote:
> > On Mon, Sep 13, 2021 at 08:41:47AM +0200, Jan Beulich wrote:
> >> --- a/xen/include/asm-arm/grant_table.h
> >> +++ b/xen/include/asm-arm/grant_table.h
> >> +if ( gfn_eq(ogfn, INVAL
On Mon, Sep 13, 2021 at 3:41 PM Stefano Stabellini
wrote:
> Hi all,
>
> This email is for anybody interested in using Argo with Dom0less setups
> for domain-to-domain communications.
>
> Argo is a secure VM-to-VM communication mechanism based on hypercalls
> [1]. It is a good fit for Dom0less set
On Wed, Sep 01, 2021 at 06:06:37PM +0200, Jan Beulich wrote:
> The function may fail; it is not correct to indicate "success" in this
> case up the call stack. Mark the function must-check to prove all
> cases have been caught (and no new ones will get introduced).
>
> Signed-off-by: Jan Beulich
> On 17 Sep 2021, at 23:33, Stefano Stabellini wrote:
>
> On Fri, 17 Sep 2021, Luca Fancellu wrote:
>>> On 16 Sep 2021, at 21:16, Stefano Stabellini wrote:
>>>
>>> On Thu, 16 Sep 2021, Jan Beulich wrote:
On 16.09.2021 17:07, Luca Fancellu wrote:
> I explain here my understanding on
On 21.09.21 10:27, Peter Zijlstra wrote:
On Tue, Sep 21, 2021 at 09:02:26AM +0200, Juergen Gross wrote:
Disabling preemption in xen_irq_enable() is not needed. There is no
risk of missing events due to preemption, as preemption can happen
only in case an event is being received, which is just th
flight 165133 qemu-mainline real [real]
flight 165138 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165133/
http://logs.test-lab.xenproject.org/osstest/logs/165138/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 21.09.2021 10:32, Roger Pau Monné wrote:
> On Mon, Sep 20, 2021 at 05:27:17PM +0200, Jan Beulich wrote:
>> On 20.09.2021 12:20, Roger Pau Monné wrote:
>>> On Mon, Sep 13, 2021 at 08:41:47AM +0200, Jan Beulich wrote:
--- a/xen/include/asm-arm/grant_table.h
+++ b/xen/include/asm-arm/gran
On 21.09.2021 11:20, Roger Pau Monné wrote:
> On Wed, Sep 01, 2021 at 06:06:37PM +0200, Jan Beulich wrote:
>> The function may fail; it is not correct to indicate "success" in this
>> case up the call stack. Mark the function must-check to prove all
>> cases have been caught (and no new ones will g
On Tue, Sep 21, 2021 at 12:28:12PM +0200, Jan Beulich wrote:
> On 21.09.2021 11:20, Roger Pau Monné wrote:
> > On Wed, Sep 01, 2021 at 06:06:37PM +0200, Jan Beulich wrote:
> >> The function may fail; it is not correct to indicate "success" in this
> >> case up the call stack. Mark the function must
Roger Pau Monné writes ("Re: [PATCH] common: guest_physmap_add_page()'s return
value needs checking"):
> On Tue, Sep 21, 2021 at 12:28:12PM +0200, Jan Beulich wrote:
> > On 21.09.2021 11:20, Roger Pau Monné wrote:
> > > On Wed, Sep 01, 2021 at 06:06:37PM +0200, Jan Beulich wrote:
> > >> The functi
On 20.09.2021 19:25, Andrew Cooper wrote:
> v2:
> * Adjust callers of HVMTRACE_ND() too
What does this refer to? The sole difference to v1 that I can spot
is ...
> * Drop _d[] for the 0 case.
... the one corresponding to this line, i.e. ...
> --- a/xen/include/asm-x86/hvm/trace.h
> +++ b/xen/
On 20.09.2021 19:25, Andrew Cooper wrote:
> * Delete trailing whitespace
> * Replace an opencoded DIV_ROUND_UP()
> * Drop bogus smp_rmb() - spin_lock_irqsave() has full smp_mb() semantics.
>
> Signed-off-by: Andrew Cooper
Like for v1: Largely
Reviewed-by: Jan Beulich
One remark:
> @@ -717,9
flight 165137 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165137/
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
flight 165134 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165134/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 17 guest-saverestorefail REGR. vs. 152332
test-amd64-amd64-do
On 20.09.2021 19:25, Andrew Cooper wrote:
> 1) vpic_ack_pending_irq() calls vlapic_accept_pic_intr() twice, once in the
>TRACE_2D() instantiation and once "for real". Make the call only once.
>
> 2) vlapic_accept_pic_intr() similarly calls __vlapic_accept_pic_intr() twice,
>although this
Hi Stefano,
> On 16 Sep 2021, at 9:26 pm, Stefano Stabellini wrote:
>
> On Thu, 16 Sep 2021, Rahul Singh wrote:
>> Hi Stefano,
>>
>>> On 10 Sep 2021, at 1:26 am, Stefano Stabellini
>>> wrote:
>>>
>>> On Thu, 19 Aug 2021, Rahul Singh wrote:
The existing VPCI support available for X86 is
flight 165136 xen-unstable real [real]
flight 165141 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165136/
http://logs.test-lab.xenproject.org/osstest/logs/165141/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
Hi Robin,
>> I use Xen PV display. In my case, PV display backend(Dom0) allocates
>> contiguous buffer via DMA-API to
>> to implement zero-copy between Dom0 and DomU.
>>
> Well, something's gone badly wrong there - if you have to shadow the
> entire thing in a bounce buffer to import it then it's
On 21/09/2021 12:00, Jan Beulich wrote:
> On 20.09.2021 19:25, Andrew Cooper wrote:
>> v2:
>> * Adjust callers of HVMTRACE_ND() too
> What does this refer to? The sole difference to v1 that I can spot
> is ...
Oh - its me who was confused.
I thought I had failed to include the changes in vmx.c/s
On 21.09.2021 17:38, Andrew Cooper wrote:
> On 21/09/2021 12:00, Jan Beulich wrote:
>> On 20.09.2021 19:25, Andrew Cooper wrote:
>>> v2:
>>> * Adjust callers of HVMTRACE_ND() too
>> What does this refer to? The sole difference to v1 that I can spot
>> is ...
>
> Oh - its me who was confused.
>
>
The xen-syms and xen.efi linking steps are serialized only when the
intermediate note.o file is necessary. Otherwise both may run in
parallel. This in turn means that the compiler / linker invocations to
create efi/check.o / efi/check.efi may also happen twice in parallel.
Obviously it's a bad idea
On 20.09.2021 19:25, Andrew Cooper wrote:
> This entire file is pv-only, and not excluded from the build by
> CONFIG_TRACEBUFFER. Move it into the pv/ directory, build it conditionally,
> and drop unused includes.
>
> Also move the contents of asm/trace.h to asm/pv/trace.h to avoid the functions
On 20.09.2021 19:25, Andrew Cooper wrote:
> The feature is x86 and pv-dom0 specific, and each architecture's main trace.h
> files are empty. Don't force all new architectures to create an empty file.
The first half sentence looks to be wrong according to Julien's
reply to patch 16. But the change
On 20.09.2021 19:25, Andrew Cooper wrote:
> Use more appropriate types.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
with a suggestion:
> @@ -48,30 +45,28 @@ void __trace_pv_page_fault(unsigned long addr, unsigned
> error_code)
>
> if ( is_pv_32bit_vcpu(current) )
> {
On 28/08/21 21:47, Peter Zijlstra wrote:
+config HAVE_GUEST_PERF_EVENTS
+ bool
depends on HAVE_KVM
It won't really do anything, since Kconfig does not detects conflicts
between select' and 'depends on' clauses.
Rather, should the symbol be selected by KVM, instead of ARM64 and
Hi Stefano
[snip]
+static void finalise_ext_region(libxl__gc *gc, struct xc_dom_image
*dom)
+{
+ void *fdt = dom->devicetree_blob;
+ uint32_t regs[(GUEST_ROOT_ADDRESS_CELLS +
GUEST_ROOT_SIZE_CELLS) * 2];
+ be32 *cells = ®s[0];
+ uint64_t region_size = 0, region_base, ban
On 21/09/2021 07:53, Jan Beulich wrote:
> On 20.09.2021 19:25, Andrew Cooper wrote:
>> In the case that 'extra' isn't a multiple of uint32_t, the calculation rounds
>> the number of bytes up, causing later logic to read unrelated bytes beyond
>> the
>> end of the object.
>>
>> Also, asserting that
On 21/09/2021 13:18, Jan Beulich wrote:
> On 20.09.2021 19:25, Andrew Cooper wrote:
>> 1) vpic_ack_pending_irq() calls vlapic_accept_pic_intr() twice, once in the
>>TRACE_2D() instantiation and once "for real". Make the call only once.
>>
>> 2) vlapic_accept_pic_intr() similarly calls __vlapic
On 21.09.21 02:21, Stefano Stabellini wrote:
Hi Stefano
On Sun, 19 Sep 2021, Oleksandr wrote:
On 18/09/2021 03:37, Stefano Stabellini wrote:
On Fri, 17 Sep 2021, Stefano Stabellini wrote:
On Fri, 17 Sep 2021, Oleksandr wrote:
+
+ dt_dprintk("Find unallocated memory for extended regions
On 21/09/2021 17:08, Jan Beulich wrote:
> On 20.09.2021 19:25, Andrew Cooper wrote:
>> Use more appropriate types.
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
Thanks.
> with a suggestion:
>
>> @@ -48,30 +45,28 @@ void __trace_pv_page_fault(unsigned long addr, unsigned
>> erro
On 18.09.21 00:56, Stefano Stabellini wrote:
Hi Stefano
On Fri, 17 Sep 2021, Oleksandr wrote:
+
+ dt_dprintk("Find unallocated memory for extended regions\n");
+
+ unalloc_mem = rangeset_new(NULL, NULL, 0);
+ if ( !unalloc_mem )
+ return -ENOMEM;
+
+ /* Start with all avai
Not a patch, but an RFC idea for one...
It occurred to me that the cycles parameter from __trace_var() and
friends is pointless, as the cycles bit is encoded in the top bit of the
event field anyway, and passed in the adjacent parameter.
Dropping the cycles parameter results in +85/-1029 (-944) n
flight 165139 qemu-mainline real [real]
flight 165144 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165139/
http://logs.test-lab.xenproject.org/osstest/logs/165144/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Tue, 21 Sep 2021, Oleksandr Andrushchenko wrote:
> On 21.09.21 10:09, Juergen Gross wrote:
> > On 21.09.21 09:00, Oleksandr Andrushchenko wrote:
> >>
> >> On 21.09.21 09:49, Juergen Gross wrote:
> >>> On 21.09.21 08:38, Oleksandr Andrushchenko wrote:
>
> On 21.09.21 09:07, Juergen Gros
On Tue, Sep 21, 2021, Paolo Bonzini wrote:
> On 28/08/21 21:47, Peter Zijlstra wrote:
> > > +config HAVE_GUEST_PERF_EVENTS
> > > + bool
> > depends on HAVE_KVM
>
> It won't really do anything, since Kconfig does not detects conflicts
> between select' and 'depends on' clauses.
It does throw a
On Tue, 21 Sep 2021, Luca Fancellu wrote:
> > On 17 Sep 2021, at 23:33, Stefano Stabellini wrote:
> > On Fri, 17 Sep 2021, Luca Fancellu wrote:
> >>> On 16 Sep 2021, at 21:16, Stefano Stabellini
> >>> wrote:
> >>>
> >>> On Thu, 16 Sep 2021, Jan Beulich wrote:
> On 16.09.2021 17:07, Luca Fa
On Tue, 21 Sep 2021, Rahul Singh wrote:
> Hi Stefano,
>
> > On 16 Sep 2021, at 9:26 pm, Stefano Stabellini
> > wrote:
> >
> > On Thu, 16 Sep 2021, Rahul Singh wrote:
> >> Hi Stefano,
> >>
> >>> On 10 Sep 2021, at 1:26 am, Stefano Stabellini
> >>> wrote:
> >>>
> >>> On Thu, 19 Aug 2021, Rahu
flight 165140 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165140/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 17 guest-saverestorefail REGR. vs. 152332
test-amd64-amd64-do
On Tue, 21 Sep 2021, Oleksandr wrote:
> On 21.09.21 02:21, Stefano Stabellini wrote:
> > On Sun, 19 Sep 2021, Oleksandr wrote:
> > > > On 18/09/2021 03:37, Stefano Stabellini wrote:
> > > > > On Fri, 17 Sep 2021, Stefano Stabellini wrote:
> > > > > > On Fri, 17 Sep 2021, Oleksandr wrote:
> > > > >
> Since it doesn't seem possible to have each boot component using the same log
> format, we added a log_format and log_phys_addr fields to give flexibility in
> how logs are stored. An example of a different log format that can be used is
> the cbmem_console log format used by coreboot:
I am not
flight 165143 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165143/
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 Wed, Sep 15, 2021, Zhu, Lingshan wrote:
>
>
> On 8/27/2021 3:59 AM, Sean Christopherson wrote:
> > TL;DR: Please don't merge this patch, it's broken and is also built on a
> > shoddy
> > foundation that I would like to fix.
> Hi Sean,Peter, Paolo
>
> I will send out an V11 which drop
On Mon, 20 Sep 2021, Ian Jackson wrote:
> Jan Beulich writes ("Re: [xen-unstable test] 164996: regressions - FAIL"):
> > As per
> >
> > Sep 15 14:44:55.502598 [ 1613.322585] Mem-Info:
> > Sep 15 14:44:55.502643 [ 1613.324918] active_anon:5639 inactive_anon:15857
> > isolated_anon:0
> > Sep 15 14:
Protect perf_guest_cbs with READ_ONCE/WRITE_ONCE to ensure it's not
reloaded between a !NULL check and a dereference, and wait for all
readers via syncrhonize_rcu() to prevent use-after-free, e.g. if the
callbacks are being unregistered during module unload. Because the
callbacks are global, it's
Peter, I left the Intel PT mess as-is. Having to pass a NULL pointer
from KVM arm64 seemed to be a lesser evil than more exports and multiple
registration paths.
This is a combination of ~2 series to fix bugs in the perf+KVM callbacks,
optimize the callbacks by employing static_call, and do a var
Wait to register perf callbacks until after doing vendor hardaware setup.
VMX's hardware_setup() configures Intel Processor Trace (PT) mode, and a
future fix to register the Intel PT guest interrupt hook if and only if
Intel PT is exposed to the guest will consume the configured PT mode.
Delaying
Override the Processor Trace (PT) interrupt handler for guest mode if and
only if PT is configured for host+guest mode, i.e. is being used
independently by both host and guest. If PT is configured for system
mode, the host fully controls PT and must handle all events.
Fixes: 8479e04e7d6b ("KVM: x
Drop the 'int' return value from the perf (un)register callbacks helpers
and stop pretending perf can support multiple callbacks. The 'int'
returns are not future proofing anything as none of the callers take
action on an error. It's also not obvious that there will ever be
co-tenant hypervisors,
Drop "support" for guest callbacks from architctures that don't implement
the guest callbacks. Future patches will convert the callbacks to
static_call; rather than churn a bunch of arch code (that was presumably
copy+pasted from x86), remove it wholesale as it's useless and at best
wasting cycles
From: Like Xu
To prepare for using static_calls to optimize perf's guest callbacks,
replace ->is_in_guest and ->is_user_mode with a new multiplexed hook
->state, tweak ->handle_intel_pt_intr to play nice with being called when
there is no active guest, and drop "guest" from ->is_in_guest.
Return
Add helpers for the guest callbacks to prepare for burying the callbacks
behind a Kconfig (it's a lot easier to provide a few stubs than to #ifdef
piles of code), and also to prepare for converting the callbacks to
static_call(). perf_instruction_pointer() in particular will have subtle
semantics
Use static_call to optimize perf's guest callbacks on arm64 and x86,
which are now the only architectures that define the callbacks. Use
DEFINE_STATIC_CALL_RET0 as the default/NULL for all guest callbacks, as
the callback semantics are that a return value '0' means "not in guest".
static_call obv
Introduce GUEST_PERF_EVENTS and require architectures to select it to
allow registering and using guest callbacks in perf. This will hopefully
make it more difficult for new architectures to add useless "support" for
guest callbacks, e.g. via copy+paste.
Stubbing out the helpers has the happy bon
Use the generic kvm_running_vcpu plus a new 'handling_intr_from_guest'
variable in kvm_arch_vcpu instead of the semi-redundant current_vcpu.
kvm_before/after_interrupt() must be called while the vCPU is loaded,
(which protects against preemption), thus kvm_running_vcpu is guaranteed
to be non-NULL
Now that all state needed for VMX's PT interrupt handler is exposed to
vmx.c (specifically the currently running vCPU), move the handler into
vmx.c where it belongs.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/vmx/vmx.c | 22 +
Differntiate between IRQ and NMI for KVM's PMC overflow callback, which
was originally invoked in response to an NMI that arrived while the guest
was running, but was inadvertantly changed to fire on IRQs as well when
support for perf without PMU/NMI was added to KVM. In practice, this
should be a
Call KVM's (un)register perf callbacks helpers directly from arm.c, and
move the PMU bits into pmu.c and rename the related helper accordingly.
Signed-off-by: Sean Christopherson
---
arch/arm64/include/asm/kvm_host.h | 3 ---
arch/arm64/kvm/Makefile | 2 +-
arch/arm64/kvm/arm.c
Move x86's perf guest callbacks into common KVM, as they are semantically
identical to arm64's callbacks (the only other such KVM callbacks).
arm64 will convert to the common versions in a future patch.
Implement the necessary arm64 arch hooks now to avoid having to provide
stubs or a temporary #d
Drop perf's stubs for (un)registering guest callbacks now that KVM
registration of callbacks is hidden behind GUEST_PERF_EVENTS=y. The only
other user is x86 XEN_PV, and x86 unconditionally selects PERF_EVENTS.
No functional change intended.
Signed-off-by: Sean Christopherson
---
include/linux
Drop arm64's version of the callbacks in favor of the callbacks provided
by generic KVM, which are semantically identical.
Signed-off-by: Sean Christopherson
---
arch/arm64/kvm/perf.c | 34 ++
1 file changed, 2 insertions(+), 32 deletions(-)
diff --git a/arch/arm
flight 165142 xen-unstable real [real]
flight 165146 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165142/
http://logs.test-lab.xenproject.org/osstest/logs/165146/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
Alec Brown wrote:
> Below is how the layout of these logs would store their data.
>
> bf_log_header:
>+---+
> u32| version |
> u32| size |
> u8[64] | producer |
> u8[64] | log_format|
>
On 22/09/21 02:05, Sean Christopherson wrote:
Wait to register perf callbacks until after doing vendor hardaware setup.
VMX's hardware_setup() configures Intel Processor Trace (PT) mode, and a
future fix to register the Intel PT guest interrupt hook if and only if
Intel PT is exposed to the guest
On 22/09/21 02:05, Sean Christopherson wrote:
Override the Processor Trace (PT) interrupt handler for guest mode if and
only if PT is configured for host+guest mode, i.e. is being used
independently by both host and guest. If PT is configured for system
mode, the host fully controls PT and must
On 22/09/21 02:05, Sean Christopherson wrote:
Drop the 'int' return value from the perf (un)register callbacks helpers
and stop pretending perf can support multiple callbacks. The 'int'
returns are not future proofing anything as none of the callers take
action on an error. It's also not obviou
On 22/09/21 02:05, Sean Christopherson wrote:
Drop "support" for guest callbacks from architctures that don't implement
the guest callbacks. Future patches will convert the callbacks to
static_call; rather than churn a bunch of arch code (that was presumably
copy+pasted from x86), remove it whol
On 22/09/21 02:05, Sean Christopherson wrote:
To prepare for using static_calls to optimize perf's guest callbacks,
replace ->is_in_guest and ->is_user_mode with a new multiplexed hook
->state, tweak ->handle_intel_pt_intr to play nice with being called when
there is no active guest, and drop "gu
On 22/09/21 02:05, Sean Christopherson wrote:
Drop perf's stubs for (un)registering guest callbacks now that KVM
registration of callbacks is hidden behind GUEST_PERF_EVENTS=y. The only
other user is x86 XEN_PV, and x86 unconditionally selects PERF_EVENTS.
No functional change intended.
Signed
On 22/09/21 02:05, Sean Christopherson wrote:
Add helpers for the guest callbacks to prepare for burying the callbacks
behind a Kconfig (it's a lot easier to provide a few stubs than to #ifdef
piles of code), and also to prepare for converting the callbacks to
static_call(). perf_instruction_poi
On 22/09/21 02:05, Sean Christopherson wrote:
Introduce GUEST_PERF_EVENTS and require architectures to select it to
allow registering and using guest callbacks in perf. This will hopefully
make it more difficult for new architectures to add useless "support" for
guest callbacks, e.g. via copy+pa
On 22/09/21 02:05, Sean Christopherson wrote:
Use static_call to optimize perf's guest callbacks on arm64 and x86,
which are now the only architectures that define the callbacks. Use
DEFINE_STATIC_CALL_RET0 as the default/NULL for all guest callbacks, as
the callback semantics are that a return
On 22/09/21 02:05, Sean Christopherson wrote:
Note, this also doesn't completely prevent false positives if perf
somehow ends up calling into KVM, e.g. an NMI can arrive in host after
KVM sets its flag.
s/calling into KVM/being called from KVM/ ?
Not sure about what you meant though. The code
On 22/09/21 02:05, Sean Christopherson wrote:
Use the generic kvm_running_vcpu plus a new 'handling_intr_from_guest'
variable in kvm_arch_vcpu instead of the semi-redundant current_vcpu.
kvm_before/after_interrupt() must be called while the vCPU is loaded,
(which protects against preemption), thu
1 - 100 of 102 matches
Mail list logo
