Qing
Your problem should be problem of credit scheduler.
If you use sedf or bvt, you would not meet the problem.
Thanks
Yunfeng
>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of He, Qing
>Sent: 2006年8月2日 16:02
>To: Steven Smith; xen-devel@xxxxxxxxxxxxxxxxxxx
>Cc: sos22@xxxxxxxxxxxxx
>Subject: RE: [Xen-devel] Paravirtualised drivers for fully virtualised domains
>
>Hi Steven,
>I found some issues regarding this patch.
>When I'm trying to start windows as VMX guest (with no drivers, of course)
>under
>this patch, the guests fail. I ran with three images, windows 2000, XP and
>2003.
>
>For 2000 and XP, QEMU windows do not show, there are two lines in the serial
>output:
> (XEN) Create event channels for vcpu 0.
> (XEN) Send on unbound Xen event channel?
>
>For 2003 guest, QEMU can start, but before the windows start screen shows, it
>crashes and restarts, complaining about unreasonable mmio opcodes. The serial
>output is:
> (XEN) (GUEST: 1) unsupported PCI BIOS function 0x0E
> (XEN) (GUEST: 1) int13_harddisk: function 15, unmapped device for
> ELDL=82
> (XEN) 0, This opcode isn't handled yet!
> (XEN) handle_mmio: failed to decode instruction
> (XEN) mmio opcode: va 0xf821f600, gpa 0xa9600, len 2: 00 00
> (XEN) domain_crash_sync called from platform.c:880
> (XEN) Domain 1 (vcpu#0) crashed on cpu#2:
> (XEN) ----[ Xen-3.0-unstable Not tainted ]----
> (XEN) CPU: 2
> (XEN) EIP: 0008:[<8081d986>]
> (XEN) EFLAGS: 00010202 CONTEXT: hvm
> (XEN) eax: 00008008 ebx: 000003ce ecx: 000003ce edx: f821f600
> (XEN) esi: 8081d9fa edi: f886ecd0 ebp: f886ecfc esp: f886ecbc
> (XEN) cr0: 8001003b cr3: 8f500000
> (XEN) ds: 0023 es: 0023 fs: 0030 gs: 0000 ss: 0010 cs: 0008
> (XEN) Create event channels for vcpu 0.
> (XEN) Send on unbound Xen event channel?
> (XEN) (GUEST: 2) HVM Loader
> (XEN) (GUEST: 2) Loading ROMBIOS ...
> (XEN) (GUEST: 2) Loading Cirrus VGABIOS ...
> (XEN) (GUEST: 2) Loading VMXAssist ...
> (XEN) (GUEST: 2) VMX go ...
> (XEN) (GUEST: 2) VMXAssist (Aug 2 2006)
> (XEN) (GUEST: 2) Memory size 512 MB
> (XEN) (GUEST: 2) E820 map:
> (XEN) (GUEST: 2) 0000000000000000 - 000000000009F800 (RAM)
> (XEN) (GUEST: 2) 000000000009F800 - 00000000000A0000 (Reserved)
> (XEN) (GUEST: 2) 00000000000A0000 - 00000000000C0000 (Type 16)
> (XEN) (GUEST: 2) 00000000000F0000 - 0000000000100000 (Reserved)
> (XEN) (GUEST: 2) 0000000000100000 - 000000001FFFE000 (RAM)
> (XEN) (GUEST: 2) 000000001FFFE000 - 000000001FFFF000 (Type 18)
> (XEN) (GUEST: 2) 000000001FFFF000 - 0000000020000000 (Type 17)
> (XEN) (GUEST: 2) 0000000020000000 - 0000000020003000 (ACPI NVS)
> (XEN) (GUEST: 2) 0000000020003000 - 000000002000D000 (ACPI Data)
> (XEN) (GUEST: 2) 00000000FEC00000 - 0000000100000000 (Type 16)
> (XEN) (GUEST: 2)
> (XEN) (GUEST: 2) Start BIOS ...
> (XEN) (GUEST: 2) Starting emulated 16-bit real-mode: ip=F000:FFF0
> (XEN) (GUEST: 2) rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $
> (XEN) (GUEST: 2) Remapping master: ICW2 0x8 -> 0x20
> (XEN) (GUEST: 2) Remapping slave: ICW2 0x70 -> 0x28
> (XEN) (GUEST: 2) VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50
>vruppert Exp $
> (XEN) (GUEST: 2) HVMAssist BIOS, 1 cpu, $Revision: 1.138 $ $Date:
>2005/05/07 15:55:26 $
> (XEN) (GUEST: 2)
> (XEN) (GUEST: 2) ata0-0: PCHS=16383/16/63 translation=lba
>LCHS=1024/255/63
> (XEN) (GUEST: 2) ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (12289
> MBytes)
> (XEN) (GUEST: 2) ata0-1: PCHS=3047/16/63 translation=lba LCHS=761/64/63
> (XEN) (GUEST: 2) ata0 slave: QEMU HARDDISK ATA-7 Hard-Disk (1500
> MBytes)
> (XEN) (GUEST: 2) ata1 master: QEMU CD-ROM ATAPI-4 CD-Rom/DVD-Rom
> (XEN) (GUEST: 2) ata1 slave: Unknown device
> (XEN) (GUEST: 2)
> (XEN) (GUEST: 2) Booting from CD-Rom...
> (XEN) (GUEST: 2) unsupported PCI BIOS function 0x0E
> (XEN) (GUEST: 2) int13_harddisk: function 15, unmapped device for
> ELDL=82
> (XEN) 0, This opcode isn't handled yet!
> (XEN) handle_mmio: failed to decode instruction
> (XEN) mmio opcode: va 0xf821f600, gpa 0xa9600, len 2: 00 00
> (XEN) domain_crash_sync called from platform.c:880
> (XEN) Domain 2 (vcpu#0) crashed on cpu#2:
> (XEN) ----[ Xen-3.0-unstable Not tainted ]----
> (XEN) CPU: 2
> (XEN) EIP: 0008:[<8081d986>]
> (XEN) EFLAGS: 00010202 CONTEXT: hvm
> (XEN) eax: 00008008 ebx: 000003ce ecx: 000003ce edx: f821f600
> (XEN) esi: 8081d9fa edi: f886ecd0 ebp: f886ecfc esp: f886ecbc
> (XEN) cr0: 8001003b cr3: 2ded8000
> (XEN) ds: 0023 es: 0023 fs: 0030 gs: 0000 ss: 0010 cs: 0008
>
>Meanwhile, I don't experience any problems for Linux guest. Do you have any
>ideas
>why this happens?
>
>Best regards,
>Qing He
>>-----Original Message-----
>>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Steven Smith
>>Sent: 2006年7月26日 23:35
>>To: xen-devel@xxxxxxxxxxxxxxxxxxx
>>Cc: sos22@xxxxxxxxxxxxx
>>Subject: Re: [Xen-devel] Paravirtualised drivers for fully virtualised domains
>>
>>I've just put an updated version of these patches up at
>>http://www.cl.cam.ac.uk/~sos22/pv-on-hvm/rev2 . There's also an
>>equivalent single big patch at
>>http://www.cl.cam.ac.uk/~sos22/pv-on-hvm/rev2.combined . Thank you to
>>everyone who gave feedback on the previous version.
>>
>>The main changes since last time are:
>>
>>-- Support for SMP guests
>>-- Support for 64 bit guests on a 64 bit hypervisor
>>-- Partial support for 32 bit guests on a 64 bit hypervisor: the network
>> interface works, but the block device doesn't.
>>
>>The block device can be made to work by #define'ing ALIEN_INTERFACES
>>in blkif.h, but drivers compiled in that way won't work with 32 on 32.
>>The problem here is that blkif_request_t contains extra padding in 64
>>bit builds, and so is a different size, and so the block ring layout
>>is different.
>>
>>Other structures with similar problems are handled either by run time
>>tests in the drivers (shared_info_t) or translation wrappers in the
>>hypervisor (xen_feature_info_t, xen_add_to_physmap_t), but trying to
>>do this for the block rings would require far more painful and
>>extensive surgery. I'm inclined to stick with multiply compiling the
>>frontend drivers in the short term, although it'll obviously need
>>doing in a slightly less grotty way.
>>
>>Steven.
>
>_______________________________________________
>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
|
Home