[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 2/3] xen/oprofile: use NMI continuation for sending virq to guest



On 12.11.20 12:05, Jan Beulich wrote:
On 12.11.2020 11:48, Jürgen Groß wrote:
On 12.11.20 11:23, Jan Beulich wrote:
On 11.11.2020 16:48, Jürgen Groß wrote:
On 11.11.20 16:45, Jan Beulich wrote:
On 09.11.2020 10:50, Juergen Gross wrote:
    static int nmi_callback(const struct cpu_user_regs *regs, int cpu)
    {
        int xen_mode, ovf;
ovf = model->check_ctrs(cpu, &cpu_msrs[cpu], regs);
        xen_mode = ring_0(regs);

Unrelated to the patch here (i.e. just as an observation), this
use of ring_0() looks bogus when the NMI occurred in HVM guest
mode.

An NMI in an HVM guest due to oprofile would be a VMEXIT with NMI
reason, or just be handled completely inside the guest, right?

Yes, and in the former case for VMX it would be handed on to do_nmi(),
with the guest register state. For SVM it would get handled on the
next STGI, i.e. would indeed never surface from HVM guest mode.

I don't see how this test should ever result in xen_mode being
false for an HVM guest.

I think, because of hvm_invalidate_regs_fields(), on VMX it would be
consistently true in release builds and consistently false in debug
ones.

Ah, okay. I searched for do_nmi(), but the vmx code uses the exception
table instead.

So I guess this should be:

xen_mode = !guest_mode(regs);


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.