RE: [Xen-devel] [PATCH] support protected mode mmio with non-zero CS base

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Jan Beulich
> Sent: 22 November 2006 07:36
> To: Petersson, Mats
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] [PATCH] support protected mode mmio 
> with non-zero CS base
> 
> >>      realmode = hvm_realmode(v);
> >>      if ( realmode )
> >> -        inst_addr = (regs->cs << 4) + regs->eip;
> >> +        inst_addr = regs->cs << 4;
> >>      else
> >> -        inst_addr = regs->eip;
> >> +        inst_addr = hvm_get_segment_base(current, seg_cs);
> >
> >Remove the "if ( realmode ) " and just use the segment base 
> address. The
> >base-address in the register should be correct even in 
> realmod, or the
> >processor is broken. [I don't think this code is being executed from
> >vmxassist - if it is, then that's a different special case!]. 
> 
> I intentionally didn't, as at least on VMX the read operation could
> be significantly slower than a shift (and due to the indirect 
> call it will
> be slower even on SVM).

Yes, but it's also possibly incorrect if the machine is in "big
realmode", which is an entirely valid way to run code in x86 processors,
and I think it's better to fix it "properly" than to have to fix it
again when someone finds another fault in the code, because someone
wrote some code differently. 

The next problem will of course be that data-fetches where the segment
base is non-zero. I think the only case where that is likely to happen
in mmio is for MOVS instructions, as everything else is presumably using
the faulting address to know where the MMIO address is. But I'm OK with
not fixing this right now. 

> 
> >Theoretically, you should also check that (eip <= segment.limit), and
> >issue GP-fault if not true. 
> 
> Again intentionally no: If the original instruction managed 
> to generate
> a page fault, than it must have been entirely within limits - 
> otherwise
> hardware would have generated a GP fault.

Yes, I agree. 

--
Mats
> 
> Jan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel