WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH]Fix the bug of guest os installation failure and

To: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH]Fix the bug of guest os installation failure and win2k boot failure
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Mon, 17 Mar 2008 10:32:31 +0000
Delivery-date: Mon, 17 Mar 2008 03:33:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <FF386CB4AE0E4648B0A96060EC00F36C8AFBD5@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AciIBgTbUv10I0dQRSWDUmWTZvY2cwAA2Hm8AABl+TAAA81x3g==
Thread-topic: [Xen-devel] [PATCH]Fix the bug of guest os installation failure and win2k boot failure
User-agent: Microsoft-Entourage/11.4.0.080122
On 17/3/08 10:06, "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx> wrote:

>     Realmode emulation code path for I/O is fine. I just think that realmode
> I/O doesn't need that line of check code.

Okay, understood and I agree.

>     For vmexit code path: When I debug this issue, I found that for some I/O
> vmexits which happened when /sbin/loader is executed, the cpl is 3, the iopl
> is 0, so when "generate_exception_if(!mode_iopl(), EXC_GP)" checks cpl and
> iopl relationship, it push out a GP fault and makes the guest installation
> fail. Actually before the code enters vmx_vmexit_handler(), the processor has
> already checked the I/O permission. So here I think that line of check code is
> not needed.

Ah, and so we assume that the I/O access is actually permitted by the TSS
I/O bitmap? Seems reasonable, and so we could add that check or just remove
the CPL-IOPL check. I agree again.

>     Also we haven't found any bug caused by the 4-instruction emulation till
> now. Adding the change in the shadow code path is because: There may be I/O
> instructions among the 4 instructions in theory. In this case, I think a full
> check of cpl, iopl, and the I/O bitmap is needed. So we may either add the I/O
> permission check in software, or break the 4-instruction emulate and let
> processor do the I/O permission check, then emulate it by
> vmx_vmexit_handler()->handle_mmio() code path. Here the patch uses the second
> way. 

I think you misunderstand. The shadow emulator *never* emulates I/O port
accesses or exception deliveries. Those callback functions are simply not
implemented and are left as NULL. Hence we will fail the IOPL check, but we
will also fail to deliver EXC_GP, and so we will simply return
X86EMUL_UNHANDLEABLE, which is the right thing to do. So, no bug here and
your changes to the shadow emulator are not required.

I will try out a version of your patch which is basically just your
x86_emulate.c changes, and see how that works out for me.

 Thanks!
 Keir



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