xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH 10/17] PVH xen: introduce vmx_pvh.c and pvh.c
Date: Tue, 30 Apr 2013 17:51:30 -0700	[thread overview]
Message-ID: <20130430175130.7cd4a1e5@mantra.us.oracle.com> (raw)
In-Reply-To: <5177B85B02000078000D03CA@nat28.tlf.novell.com>

On Wed, 24 Apr 2013 09:47:55 +0100
"Jan Beulich" <JBeulich@suse.com> wrote:

> >>> On 23.04.13 at 23:25, Mukesh Rathor <mukesh.rathor@oracle.com>
> >>> wrote:
> > @@ -1503,7 +1503,8 @@ void vmx_do_resume(struct vcpu *v)
> >  
> >          vmx_clear_vmcs(v);
> >          vmx_load_vmcs(v);
> > -        if ( !is_pvh_vcpu(v) ) {
> > +        if ( !is_pvh_vcpu(v) )
> > +        {
> 
> Surely an unnecessary adjustment, if an earlier patch got it right
> from the beginning?

Hmm... I don't understand lot of the time code, but PVH uses PV time
ops right now, so don't need to worry about it. But the time thing needs
a revisit anyways with more vtsc modes added in phase II.

> > +    };
> > +
> > +    regs->eip += ilen;
> > +
> > +    /* gdbsx or another debugger. Never pause dom0 */
> > +    if ( vp->domain->domain_id != 0 && guest_kernel_mode(vp,
> > regs) )
> > +    {
> > +        dbgp1("[%d]PVH: domain pause for debugger\n",
> > smp_processor_id());
> > +        current->arch.gdbsx_vcpu_event = TRAP_int3;
> > +        domain_pause_for_debugger();
> > +        return 0;
> > +    }
> > +
> > +    regs->eip -= ilen;
> 
> Please move the first adjustment into the if() body, making the
> second adjustment here unnecessary.

Actually, there could more debuggers being used also, so if you don't
mind i'd like to leave it as is:

    regs->eip += ilen;

#if defined(XEN_KDB_CONFIG)
    if ( kdb_handle_trap_entry(TRAP_int3, regs) )
        return 0;
#endif
    /* gdbsx or another debugger. Never pause dom0 */
    if ( vp->domain->domain_id != 0 && guest_kernel_mode(vp, regs) )
......


> > +static int vmxit_invalid_op(struct cpu_user_regs *regs)
> > +{
> > +    ulong addr = 0;
> > +
> > +    if ( guest_kernel_mode(current, regs) ||
> > +         emulate_forced_invalid_op(regs, &addr) == 0 )
> > +    {
> > +        hvm_inject_hw_exception(TRAP_invalid_op,
> > HVM_DELIVER_NO_ERROR_CODE);
> > +        return 0;
> > +    }
> > +    if ( addr )
> > +        hvm_inject_page_fault(0, addr);
> 
> This cannot be conditional upon addr being non-zero.

Why not? rc = emulate_forced_invalid_op():

   rc == 0 =>  not a valid emul signature. inject #UD.
   rc == 1 && addr != 0 => copy failed, need to inject PF
   rc == 1 && addr == 0 => emul done succesfully 

 
> > +static int access_cr4(struct cpu_user_regs *regs, uint acc_typ,
> > uint64_t *regp) +{
> > +    if ( acc_typ == VMX_CONTROL_REG_ACCESS_TYPE_MOV_TO_CR )
> > +    {
> > +        u64 old_cr4 = __vmread(GUEST_CR4);
> > +
> > +        if ( (old_cr4 ^ (*regp)) & (X86_CR4_PSE | X86_CR4_PGE |
> > X86_CR4_PAE) )
> > +            vpid_sync_all();
> > +
> > +        __vmwrite(GUEST_CR4, *regp);
> 
> No modification of CR4_READ_SHADOW here?

Added. BTW, I think I need to also set following unconditionally: 

     *regp |= X86_CR4_VMXE | X86_CR4_MCE;
     __vmwrite(GUEST_CR4, *regp);

in case the guest is turning them off.
 
> > +static int vmxit_io_instr(struct cpu_user_regs *regs)
> > +{
> > +    int curr_lvl;
> > +    int requested = (regs->rflags >> 12) & 3;
> > +
> > +    read_vmcs_selectors(regs);
> > +    curr_lvl = regs->cs & 3;
> 
> Shouldn't you look at SS'es DPL instead?

Ok. It looks like CPL is stored in both CS and SS, so either
should be ok. But I changed it to ss. 

> > +    switch ( (uint16_t)exit_reason )
> > +    {
> > +        case EXIT_REASON_EXCEPTION_NMI:      /* 0 */
> > +            rc = vmxit_exception(regs);
> > +            break;
> 
> Why would an NMI be blindly reflected to the guest?

I wish it was named EXIT_REASON_EXCEPTION_OR_NMI.
Anyways, TRAP_machine_check is handled in caller. We handle other 
excpetions here.
 
> > +        case EXIT_REASON_CPUID:              /* 10 */
> > +        {
> > +            if ( guest_kernel_mode(vp, regs) )
> > +                pv_cpuid(regs);
> > +            else
> > +                pvh_user_cpuid(regs);
> 
> What's the reason for this distinction? I would think it's actually a
> benefit of PVH to allow also hiding unwanted features from guest
> user mode (like HVM, but unlike PV without CPUID faulting).

I was trying to keep it exactly as PV where a user mode would not
be trapped. I will just call pv_cpuid() for both then.
 
> > +int vmx_pvh_read_descriptor(unsigned int sel, const struct vcpu *v,
> > +                            const struct cpu_user_regs *regs,
> > +                            unsigned long *base, unsigned long
> > *limit,
> > +                            unsigned int *ar)
> > +{
> > +    unsigned int tmp_ar = 0;
> > +    ASSERT(v == current);
> > +    ASSERT(is_pvh_vcpu(v));
> > +
> > +    if ( sel == (unsigned int)regs->cs )
> > +    {
> > +        *base = __vmread(GUEST_CS_BASE);
> > +        *limit = __vmread(GUEST_CS_LIMIT);
> > +        tmp_ar = __vmread(GUEST_CS_AR_BYTES);
> > +    }
> > +    else if ( sel == (unsigned int)regs->ds )
> 
> This if/else-if sequence can't be right - a selector can be in more
> than one selector register (and one of them may have got reloaded
> after a GDT/LDT adjustment, while another may not), so you can't
> base the descriptor read upon the selector value. The caller will
> have to tell you which register it wants the descriptor for, not which
> selector.

Ah, right! Duh. I must have made the change same time as the read_sreg
macro.
 
thanks a lot for your time.
Mukesh

  parent reply	other threads:[~2013-05-01  0:51 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-23 21:25 [PATCH 00/17][V4]: PVH xen: version 4 patches Mukesh Rathor
2013-04-23 21:25 ` [PATCH 01/17] PVH xen: turn gdb_frames/gdt_ents into union Mukesh Rathor
2013-04-23 21:25 ` [PATCH 02/17] PVH xen: add XENMEM_add_to_physmap_range Mukesh Rathor
2013-04-23 21:25 ` [PATCH 03/17] PVH xen: create domctl_memory_mapping() function Mukesh Rathor
2013-04-24  7:01   ` Jan Beulich
2013-04-23 21:25 ` [PATCH 04/17] PVH xen: add params to read_segment_register Mukesh Rathor
2013-04-23 21:25 ` [PATCH 05/17] PVH xen: vmx realted preparatory changes for PVH Mukesh Rathor
2013-04-23 21:25 ` [PATCH 06/17] PVH xen: Introduce PVH guest type Mukesh Rathor
2013-04-24  7:07   ` Jan Beulich
2013-04-24 23:01     ` Mukesh Rathor
2013-04-25  8:28       ` Jan Beulich
2013-04-23 21:25 ` [PATCH 07/17] PVH xen: tools changes to create PVH domain Mukesh Rathor
2013-04-24  7:10   ` Jan Beulich
2013-04-24 23:02     ` Mukesh Rathor
2013-04-23 21:25 ` [PATCH 08/17] PVH xen: domain creation code changes Mukesh Rathor
2013-04-23 21:25 ` [PATCH 09/17] PVH xen: create PVH vmcs, and also initialization Mukesh Rathor
2013-04-24  7:42   ` Jan Beulich
2013-04-30 21:01     ` Mukesh Rathor
2013-04-30 21:04     ` Mukesh Rathor
2013-04-23 21:25 ` [PATCH 10/17] PVH xen: introduce vmx_pvh.c and pvh.c Mukesh Rathor
2013-04-24  8:47   ` Jan Beulich
2013-04-25  0:57     ` Mukesh Rathor
2013-04-25  8:36       ` Jan Beulich
2013-04-26  1:16         ` Mukesh Rathor
2013-04-26  1:58           ` Mukesh Rathor
2013-04-26  7:29             ` Jan Beulich
2013-04-26  7:20           ` Jan Beulich
2013-04-27  2:06             ` Mukesh Rathor
2013-05-01  0:51     ` Mukesh Rathor [this message]
2013-05-01 13:52       ` Jan Beulich
2013-05-02  1:10         ` Mukesh Rathor
2013-05-02  6:42           ` Jan Beulich
2013-05-03  1:03             ` Mukesh Rathor
2013-05-10  1:51         ` Mukesh Rathor
2013-05-10  7:07           ` Jan Beulich
2013-05-10 23:44             ` Mukesh Rathor
2013-05-02  1:17     ` Mukesh Rathor
2013-05-02  6:53       ` Jan Beulich
2013-05-03  0:40         ` Mukesh Rathor
2013-05-03  6:33           ` Jan Beulich
2013-05-04  1:40             ` Mukesh Rathor
2013-05-06  6:44               ` Jan Beulich
2013-05-07  1:25                 ` Mukesh Rathor
2013-05-07  8:07                   ` Jan Beulich
2013-05-11  0:30     ` Mukesh Rathor
2013-04-25 11:19   ` Tim Deegan
2013-04-23 21:26 ` [PATCH 11/17] PVH xen: some misc changes like mtrr, intr, msi Mukesh Rathor
2013-04-23 21:26 ` [PATCH 12/17] PVH xen: support invalid op, return PVH features etc Mukesh Rathor
2013-04-24  9:01   ` Jan Beulich
2013-04-25  1:01     ` Mukesh Rathor
2013-04-23 21:26 ` [PATCH 13/17] PVH xen: p2m related changes Mukesh Rathor
2013-04-25 11:28   ` Tim Deegan
2013-04-25 21:59     ` Mukesh Rathor
2013-04-26  8:53       ` Tim Deegan
2013-04-23 21:26 ` [PATCH 14/17] PVH xen: Add and remove foreign pages Mukesh Rathor
2013-04-25 11:38   ` Tim Deegan
2013-04-23 21:26 ` [PATCH 15/17] PVH xen: Miscellaneous changes Mukesh Rathor
2013-04-24  9:06   ` Jan Beulich
2013-05-10  1:54     ` Mukesh Rathor
2013-05-10  7:10       ` Jan Beulich
2013-04-23 21:26 ` [PATCH 16/17] PVH xen: elf and iommu related changes to prep for dom0 PVH Mukesh Rathor
2013-04-24  9:15   ` Jan Beulich
2013-05-14  1:16     ` Mukesh Rathor
2013-05-14  6:56       ` Jan Beulich
2013-05-14 19:14         ` Mukesh Rathor
2013-04-23 21:26 ` [PATCH 17/17] PVH xen: PVH dom0 creation Mukesh Rathor
2013-04-24  9:28   ` Jan Beulich
2013-04-26  1:18     ` Mukesh Rathor
2013-04-26  7:22       ` Jan Beulich
2013-05-10  1:53         ` Mukesh Rathor
2013-05-10  7:14           ` Jan Beulich
2013-05-15  1:18             ` Mukesh Rathor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130430175130.7cd4a1e5@mantra.us.oracle.com \
    --to=mukesh.rathor@oracle.com \
    --cc=JBeulich@suse.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).