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
next prev 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).