[edk2] USB Keyboard/Mouse Support in OVMF

[Adhyas Avasthi]

Hello

I just noticed that OVMF does not include any USB drivers in its dsc files.
Can I not use VM's USB Keyboard/Mouse in the regular OVMF based BIOS for a
qemu created VM?
I usually use a custom VM and do not use any PS2 or legacy stuff.

Did anyone try that in their own tree? Any recommendation of the drivers I
can try to use from the EDK 2 code to hope it may just work out of the box?

--
Adhyas
********************************************************************
Two types have compatible type if their types are the same.
— ANSI C Standard, 3.1.2.6.
********************************************************************

[Adhyas Avasthi]

Some more debugging information. I have a custom VM that uses Cirrus VGA,
x86 CPU but not the PIIX3/PIIX4 chipset. I have created a small dummy
chipset and use it to initialize the necessary device. I can boot ovmf to
shell. But no keyboard/mouse. I have initialized the Uhci controller from
qemu (and it runs fine). Also added a USB keyboard to qemu.

I also added the following drivers to ovmf x64

UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf

MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf
MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf
MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf

MdeModulePkg/Bus/Usb/UsbMouseAbsolutePointerDxe/UsbMouseAbsolutePointerDxe.inf
MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouseDxe.inf

But still no input capability.
I added a debug print in UhciDxe driver but the DriverBinding Start routine
is never invoked either. Any pointers?

Thanks,
Adhyas


On Mon, Oct 25, 2010 at 6:20 PM, Adhyas Avasthi <***@gmail.com> wrote:

> Hello
>
> I just noticed that OVMF does not include any USB drivers in its dsc files.
> Can I not use VM's USB Keyboard/Mouse in the regular OVMF based BIOS for a
> qemu created VM?
> I usually use a custom VM and do not use any PS2 or legacy stuff.
>
> Did anyone try that in their own tree? Any recommendation of the drivers I
> can try to use from the EDK 2 code to hope it may just work out of the box?
>
> --
> Adhyas
> ********************************************************************
> Two types have compatible type if their types are the same.
> — ANSI C Standard, 3.1.2.6.
> ********************************************************************
>



--
Adhyas
********************************************************************
Two types have compatible type if their types are the same.
— ANSI C Standard, 3.1.2.6.
********************************************************************

[Tian, Feng]

Hi,
Which bus/device/function number does QEMU assign your emulated UHCI host controller? Could you add debug info to see if PciBus driver enumerate the UHCI host controller or not?

Thanks
Tian Feng
From: Adhyas Avasthi [mailto:***@gmail.com]
Sent: Tuesday, October 26, 2010 9:36 AM
To: edk2-***@lists.sourceforge.net
Subject: Re: [edk2] USB Keyboard/Mouse Support in OVMF

Some more debugging information. I have a custom VM that uses Cirrus VGA, x86 CPU but not the PIIX3/PIIX4 chipset. I have created a small dummy chipset and use it to initialize the necessary device. I can boot ovmf to shell. But no keyboard/mouse. I have initialized the Uhci controller from qemu (and it runs fine). Also added a USB keyboard to qemu.

I also added the following drivers to ovmf x64

UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf

MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf
MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf
MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
MdeModulePkg/Bus/Usb/UsbMouseAbsolutePointerDxe/UsbMouseAbsolutePointerDxe.inf
MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouseDxe.inf

But still no input capability.
I added a debug print in UhciDxe driver but the DriverBinding Start routine is never invoked either. Any pointers?

Thanks,
Adhyas

On Mon, Oct 25, 2010 at 6:20 PM, Adhyas Avasthi <***@gmail.com<mailto:***@gmail.com>> wrote:
Hello

I just noticed that OVMF does not include any USB drivers in its dsc files. Can I not use VM's USB Keyboard/Mouse in the regular OVMF based BIOS for a qemu created VM?
I usually use a custom VM and do not use any PS2 or legacy stuff.

Did anyone try that in their own tree? Any recommendation of the drivers I can try to use from the EDK 2 code to hope it may just work out of the box?

--
Adhyas
********************************************************************
Two types have compatible type if their types are the same.
- ANSI C Standard, 3.1.2.6.
********************************************************************



--
Adhyas
********************************************************************
Two types have compatible type if their types are the same.
- ANSI C Standard, 3.1.2.6.
********************************************************************

[Adhyas]

It's custom. I gave it devfn of 0x20 which is bus 0 dev 4 fn 0. My bus 0 is quite sparse with devices at 0, 4, 28, 29 etc. Should it really matter which pci devfn I use? I will check the efi driver code to see if it matters when I reach home.

The efi pci bus driver does find the other devfn at dev 28, 29 etc.

Sent from my iPhone

On Oct 25, 2010, at 6:53 PM, "Tian, Feng" <***@intel.com> wrote:

> Hi,
>
> Which bus/device/function number does QEMU assign your emulated UHCI host controller? Could you add debug info to see if PciBus driver enumerate the UHCI host controller or not?
>
>
>
> Thanks
>
> Tian Feng
>
> From: Adhyas Avasthi [mailto:***@gmail.com]
> Sent: Tuesday, October 26, 2010 9:36 AM
> To: edk2-***@lists.sourceforge.net
> Subject: Re: [edk2] USB Keyboard/Mouse Support in OVMF
>
>
>
> Some more debugging information. I have a custom VM that uses Cirrus VGA, x86 CPU but not the PIIX3/PIIX4 chipset. I have created a small dummy chipset and use it to initialize the necessary device. I can boot ovmf to shell. But no keyboard/mouse. I have initialized the Uhci controller from qemu (and it runs fine). Also added a USB keyboard to qemu.
>
> I also added the following drivers to ovmf x64
>
> UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
>
> MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf
> MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf
> MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
> MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
> MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
> MdeModulePkg/Bus/Usb/UsbMouseAbsolutePointerDxe/UsbMouseAbsolutePointerDxe.inf
> MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouseDxe.inf
>
> But still no input capability.
> I added a debug print in UhciDxe driver but the DriverBinding Start routine is never invoked either. Any pointers?
>
> Thanks,
> Adhyas
>
>
> On Mon, Oct 25, 2010 at 6:20 PM, Adhyas Avasthi <***@gmail.com> wrote:
>
> Hello
>
> I just noticed that OVMF does not include any USB drivers in its dsc files. Can I not use VM's USB Keyboard/Mouse in the regular OVMF based BIOS for a qemu created VM?
> I usually use a custom VM and do not use any PS2 or legacy stuff.
>
> Did anyone try that in their own tree? Any recommendation of the drivers I can try to use from the EDK 2 code to hope it may just work out of the box?
>
> --
> Adhyas
> ********************************************************************
> Two types have compatible type if their types are the same.
> — ANSI C Standard, 3.1.2.6.
> ********************************************************************
>
>
>
>
> --
> Adhyas
> ********************************************************************
> Two types have compatible type if their types are the same.
> — ANSI C Standard, 3.1.2.6.
> ********************************************************************
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> edk2-devel mailing list
> edk2-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

[Tian, Feng]

As you say UHCI driver doesn’t run, so it should be DriverBindingSupported() return error.
DriverBindingSupported() just read pci config header and judge the class code to see if it’s ehci or uhci.
From your description, it seems the emulated device has problem.

You can boot to shell, run “devices” command to list all pci devices. Run “dh –d xx” to get handle info to double confirm that.

Thanks
Tian Feng
From: Adhyas [mailto:***@gmail.com]
Sent: Tuesday, October 26, 2010 9:58 AM
To: edk2-***@lists.sourceforge.net
Cc: edk2-***@lists.sourceforge.net
Subject: Re: [edk2] USB Keyboard/Mouse Support in OVMF

It's custom. I gave it devfn of 0x20 which is bus 0 dev 4 fn 0. My bus 0 is quite sparse with devices at 0, 4, 28, 29 etc. Should it really matter which pci devfn I use? I will check the efi driver code to see if it matters when I reach home.

The efi pci bus driver does find the other devfn at dev 28, 29 etc.

Sent from my iPhone

On Oct 25, 2010, at 6:53 PM, "Tian, Feng" <***@intel.com<mailto:***@intel.com>> wrote:
Hi,
Which bus/device/function number does QEMU assign your emulated UHCI host controller? Could you add debug info to see if PciBus driver enumerate the UHCI host controller or not?

Thanks
Tian Feng
From: Adhyas Avasthi [mailto:***@gmail.com]
Sent: Tuesday, October 26, 2010 9:36 AM
To: edk2-***@lists.sourceforge.net<mailto:edk2-***@lists.sourceforge.net>
Subject: Re: [edk2] USB Keyboard/Mouse Support in OVMF

Some more debugging information. I have a custom VM that uses Cirrus VGA, x86 CPU but not the PIIX3/PIIX4 chipset. I have created a small dummy chipset and use it to initialize the necessary device. I can boot ovmf to shell. But no keyboard/mouse. I have initialized the Uhci controller from qemu (and it runs fine). Also added a USB keyboard to qemu.

I also added the following drivers to ovmf x64

UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf

MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf
MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf
MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
MdeModulePkg/Bus/Usb/UsbMouseAbsolutePointerDxe/UsbMouseAbsolutePointerDxe.inf
MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouseDxe.inf

But still no input capability.
I added a debug print in UhciDxe driver but the DriverBinding Start routine is never invoked either. Any pointers?

Thanks,
Adhyas


On Mon, Oct 25, 2010 at 6:20 PM, Adhyas Avasthi <***@gmail.com<mailto:***@gmail.com>> wrote:
Hello

I just noticed that OVMF does not include any USB drivers in its dsc files. Can I not use VM's USB Keyboard/Mouse in the regular OVMF based BIOS for a qemu created VM?
I usually use a custom VM and do not use any PS2 or legacy stuff.

Did anyone try that in their own tree? Any recommendation of the drivers I can try to use from the EDK 2 code to hope it may just work out of the box?

--
Adhyas
********************************************************************
Two types have compatible type if their types are the same.
— ANSI C Standard, 3.1.2.6.
********************************************************************



--
Adhyas
********************************************************************
Two types have compatible type if their types are the same.
— ANSI C Standard, 3.1.2.6.
********************************************************************
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
edk2-devel mailing list
edk2-***@lists.sourceforge.net<mailto:edk2-***@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[Adhyas Avasthi]

Interestingly, the Supported routine is never invoked either. I just checked
that if the Supported routine was really invoked for this device, it would
have returned SUCCESS, but it never was invoked.
The Serial dump tells me that the PCI Bus did find the device at devfn 0x20
on scan. How come it never called the USB handler? Do I need to add any
other driver as well?

Thanks,
Adhyas

On Mon, Oct 25, 2010 at 7:23 PM, Tian, Feng <***@intel.com> wrote:

> As you say UHCI driver doesn’t run, so it should be
> DriverBindingSupported() return error.
>
> DriverBindingSupported() just read pci config header and judge the class
> code to see if it’s ehci or uhci.
>

[Kinney, Michael D]

Is a handle with the PCI I/O Protocol for your device present in the handle database. You can use the "dh -p pciio" from the shell to list all the PCI device that the PCI Bus Driver discovered.

You can also use the "pci" shell command to see if it looks like a proper PCI device.

Mike

________________________________
From: Adhyas Avasthi [mailto:***@gmail.com]
Sent: Tuesday, October 26, 2010 11:33 AM
To: edk2-***@lists.sourceforge.net
Subject: Re: [edk2] USB Keyboard/Mouse Support in OVMF

Interestingly, the Supported routine is never invoked either. I just checked that if the Supported routine was really invoked for this device, it would have returned SUCCESS, but it never was invoked.
The Serial dump tells me that the PCI Bus did find the device at devfn 0x20 on scan. How come it never called the USB handler? Do I need to add any other driver as well?

Thanks,
Adhyas
On Mon, Oct 25, 2010 at 7:23 PM, Tian, Feng <***@intel.com<mailto:***@intel.com>> wrote:
As you say UHCI driver doesn't run, so it should be DriverBindingSupported() return error.
DriverBindingSupported() just read pci config header and judge the class code to see if it's ehci or uhci.

[Jordan Justen]

[Adhyas Avasthi]

Yes, I did not realize that I also needed to modify the fdf file to include
the Usb drivers there as well. I modified the dsc file (as I used to do in
EDK 1) and that did not work. Thanks for all the responses. It does work for
me now and I can have USB input.

Thanks,
Adhyas


On Tue, Oct 26, 2010 at 3:11 PM, Jordan Justen <***@gmail.com> wrote:

> Adhyas,
>
> I was able to enable USB keyboard with the attached patch while using
> qemu 0.12.3.
> I added '-usb -usbdevice keyboard' to the qemu command line.
>
> You can also comment UsbKbDxe.inf line in the .fdf to verify that ovmf
> will not have any console input after booting.
>
> -Jordan
>
> On Tue, Oct 26, 2010 at 11:33, Adhyas Avasthi <***@gmail.com> wrote:
> > Interestingly, the Supported routine is never invoked either. I just
> checked
> > that if the Supported routine was really invoked for this device, it
> would
> > have returned SUCCESS, but it never was invoked.
> > The Serial dump tells me that the PCI Bus did find the device at devfn
> 0x20
> > on scan. How come it never called the USB handler? Do I need to add any
> > other driver as well?
> >
> > Thanks,
> > Adhyas
> >
> > On Mon, Oct 25, 2010 at 7:23 PM, Tian, Feng <***@intel.com> wrote:
> >>
> >> As you say UHCI driver doesn’t run, so it should be
> >> DriverBindingSupported() return error.
> >>
> >> DriverBindingSupported() just read pci config header and judge the class
> >> code to see if it’s ehci or uhci.
> >>

[Adhyas Avasthi]

Moving forward on this effort, I am now trying to boot SUSE Linux x64 11.3
version which supports EFI. I am using a default QEMU VM for that, so no
customizations there. Has anyone tried that with success?

I can see the boot loader and it loads kernel and initrd but resets the VM
soon after it loads the files and tries to execute them.
I will spend some more cycles to debug this further but if there are
pointers I will appreciate them.

Thanks,
Adhyas

On Tue, Oct 26, 2010 at 3:20 PM, Adhyas Avasthi <***@gmail.com> wrote:

> Yes, I did not realize that I also needed to modify the fdf file to include
> the Usb drivers there as well. I modified the dsc file (as I used to do in
> EDK 1) and that did not work. Thanks for all the responses. It does work for
> me now and I can have USB input.
>
> Thanks,
> Adhyas
>
>
>
> On Tue, Oct 26, 2010 at 3:11 PM, Jordan Justen <***@gmail.com> wrote:
>
>> Adhyas,
>>
>> I was able to enable USB keyboard with the attached patch while using
>> qemu 0.12.3.
>> I added '-usb -usbdevice keyboard' to the qemu command line.
>>
>> You can also comment UsbKbDxe.inf line in the .fdf to verify that ovmf
>> will not have any console input after booting.
>>
>> -Jordan
>>
>> On Tue, Oct 26, 2010 at 11:33, Adhyas Avasthi <***@gmail.com> wrote:
>> > Interestingly, the Supported routine is never invoked either. I just
>> checked
>> > that if the Supported routine was really invoked for this device, it
>> would
>> > have returned SUCCESS, but it never was invoked.
>> > The Serial dump tells me that the PCI Bus did find the device at devfn
>> 0x20
>> > on scan. How come it never called the USB handler? Do I need to add any
>> > other driver as well?
>> >
>> > Thanks,
>> > Adhyas
>> >
>> > On Mon, Oct 25, 2010 at 7:23 PM, Tian, Feng <***@intel.com>
>> wrote:
>> >>
>> >> As you say UHCI driver doesn’t run, so it should be
>> >> DriverBindingSupported() return error.
>> >>
>> >> DriverBindingSupported() just read pci config header and judge the
>> class
>> >> code to see if it’s ehci or uhci.
>> >>

[Jordan Justen]

[Adhyas Avasthi]

Hi Jordan

Ubuntu 10.10 x64 does not work for me. It does bring up the boot loader
fine, but does not succeed with the actual boot.
The loader complains Boot Failed.0 and Boot Failed.1 and then shows me the
loader screen. I choose "Try Ubuntu without installing" but it says "error:
cannot allocate protected mode pages. error: you need to load the kernel
first." On trying it the second time without a reboot, it says "cannot
allocate pages. Aborted. Press any key to exit."

I tried with both kvm and no-kvm options, but the same end result. Note that
my host is 10.04 64bit. Should that matter? I am using the
OVMF-X64-r9029-alpha.zip version
Attached is the serial dump from the VM

Thanks,
Adhyas

On Tue, Oct 26, 2010 at 4:46 PM, Jordan Justen <***@gmail.com> wrote:

> Adhyas,
>
> I have successfully loaded Ubuntu 10.10 x86-64 which now supports UEFI.
>
> I have also loaded Fedora 12's special UEFI boot.iso from:
>
> http://download.fedoraproject.org/pub/fedora/linux/releases/12/Fedora/x86_64/os/images/
>
> But, the same image from Fedora 13 failed to boot on OVMF.
>
> You should also try adding the '-no-kvm' option to qemu. I think kvm
> should work in some cases, but if you are having trouble, give it a
> shot.
>
> -Jordan
>
> On Tue, Oct 26, 2010 at 16:34, Adhyas Avasthi <***@gmail.com> wrote:
> > Moving forward on this effort, I am now trying to boot SUSE Linux x64
> 11.3
> > version which supports EFI. I am using a default QEMU VM for that, so no
> > customizations there. Has anyone tried that with success?
> >
> > I can see the boot loader and it loads kernel and initrd but resets the
> VM
> > soon after it loads the files and tries to execute them.
> > I will spend some more cycles to debug this further but if there are
> > pointers I will appreciate them.
> >
> > Thanks,
> > Adhyas
> >
> > On Tue, Oct 26, 2010 at 3:20 PM, Adhyas Avasthi <***@gmail.com>
> wrote:
> >>
> >> Yes, I did not realize that I also needed to modify the fdf file to
> >> include the Usb drivers there as well. I modified the dsc file (as I
> used to
> >> do in EDK 1) and that did not work. Thanks for all the responses. It
> does
> >> work for me now and I can have USB input.
> >>
> >> Thanks,
> >> Adhyas
> >>
> >>
> >> On Tue, Oct 26, 2010 at 3:11 PM, Jordan Justen <***@gmail.com>
> wrote:
> >>>
> >>> Adhyas,
> >>>
> >>> I was able to enable USB keyboard with the attached patch while using
> >>> qemu 0.12.3.
> >>> I added '-usb -usbdevice keyboard' to the qemu command line.
> >>>
> >>> You can also comment UsbKbDxe.inf line in the .fdf to verify that ovmf
> >>> will not have any console input after booting.
> >>>
> >>> -Jordan
> >>>
> >>> On Tue, Oct 26, 2010 at 11:33, Adhyas Avasthi <***@gmail.com>
> wrote:
> >>> > Interestingly, the Supported routine is never invoked either. I just
> >>> > checked
> >>> > that if the Supported routine was really invoked for this device, it
> >>> > would
> >>> > have returned SUCCESS, but it never was invoked.
> >>> > The Serial dump tells me that the PCI Bus did find the device at
> devfn
> >>> > 0x20
> >>> > on scan. How come it never called the USB handler? Do I need to add
> any
> >>> > other driver as well?
> >>> >
> >>> > Thanks,
> >>> > Adhyas
> >>> >
> >>> > On Mon, Oct 25, 2010 at 7:23 PM, Tian, Feng <***@intel.com>
> >>> > wrote:
> >>> >>
> >>> >> As you say UHCI driver doesn’t run, so it should be
> >>> >> DriverBindingSupported() return error.
> >>> >>
> >>> >> DriverBindingSupported() just read pci config header and judge the
> >>> >> class
> >>> >> code to see if it’s ehci or uhci.
> >>> >>

[Adhyas Avasthi]

Also, this was done on default qemu installation and default qemu vm.
I did apt-get install KVM qemu; and qemu-system-x86-64 -no-kvm -m 1024
- L <abcd> -cdrom <ubuntu10.10.x64.iso> -serial file:temp

Thanks,
Adhyas

On Sunday, October 31, 2010, Adhyas Avasthi <***@gmail.com> wrote:
> Hi Jordan
>
> Ubuntu 10.10 x64 does not work for me. It does bring up the boot loader fine, but does not succeed with the actual boot.
> The loader complains Boot Failed.0 and Boot Failed.1 and then shows me the loader screen. I choose "Try Ubuntu without installing" but it says "error: cannot allocate protected mode pages. error: you need to load the kernel first." On trying it the second time without a reboot, it says "cannot allocate pages. Aborted. Press any key to exit."
>
> I tried with both kvm and no-kvm options, but the same end result. Note that my host is 10.04 64bit. Should that matter? I am using the OVMF-X64-r9029-alpha.zip version
> Attached is the serial dump from the VM
>
> Thanks,
> Adhyas
>
> On Tue, Oct 26, 2010 at 4:46 PM, Jordan Justen <***@gmail.com> wrote:
>
> Adhyas,
>
> I have successfully loaded Ubuntu 10.10 x86-64 which now supports UEFI.
>
> I have also loaded Fedora 12's special UEFI boot.iso from:
> http://download.fedoraproject.org/pub/fedora/linux/releases/12/Fedora/x86_64/os/images/
>
> But, the same image from Fedora 13 failed to boot on OVMF.
>
> You should also try adding the '-no-kvm' option to qemu.  I think kvm
> should work in some cases, but if you are having trouble, give it a
> shot.
>
> -Jordan
>
> On Tue, Oct 26, 2010 at 16:34, Adhyas Avasthi <***@gmail.com> wrote:
>> Moving forward on this effort, I am now trying to boot SUSE Linux x64 11.3
>> version which supports EFI. I am using a default QEMU VM for that, so no
>> customizations there. Has anyone tried that with success?
>>
>> I can see the boot loader and it loads kernel and initrd but resets the VM
>> soon after it loads the files and tries to execute them.
>> I will spend some more cycles to debug this further but if there are
>> pointers I will appreciate them.
>>
>> Thanks,
>> Adhyas
>>
>> On Tue, Oct 26, 2010 at 3:20 PM, Adhyas Avasthi <***@gmail.com> wrote:
>>>
>>> Yes, I did not realize that I also needed to modify the fdf file to
>>> include the Usb drivers there as well. I modified the dsc file (as I used to
>>> do in EDK 1) and that did not work. Thanks for all the responses. It does
>>> work for me now and I can have USB input.
>>>
>>> Thanks,
>>> Adhyas
>>>
>>>
>>> On Tue, Oct 26, 2010 at 3:11 PM, Jordan Justen <***@gmail.com> wrote:
>>>>
>>>> Adhyas,
>>>>
>>>> I was able to enable USB keyboard with the attached patch while using
>>>> qemu 0.12.3.
>>>> I added '-usb -usbdevice keyboard' to the qemu command line.
>>>>
>>>> You can also comment UsbKbDxe.inf line in the .fdf to verify that ovmf
>>>> will not have any console input after booting.
>>>>
>>>> -Jordan
>>>>
>>>> On Tue, Oct 26, 2010 at 11:33, Adhyas Avasthi <***@gmail.com> wrote:
>>>> > Interestingly, the Supported routine is never invoked either. I just
>>>> > checked
>>>> > that if the Supported routine was really invoked for this device, it
>>>> > would
>>>> > have returned SUCCESS, but it never was invoked.
>>>> > The Serial dump tells me that the PCI Bus did find the device at devfn
>>>> > 0x20
>>>> > on scan. How come it never called the USB handler? Do I need to add any
>>>> > other driver as well?
>>>> >
>>>> > Thanks,
>>>> > Adhyas
>>>> >
>>>> > On Mon, Oct 25, 2010 at 7:23 PM, Tian, Feng <***@intel.com>
>>>> > wrote:
>>>> >>
>>>> >> As you say UHCI driver doesn’t run, so it should be
>>>> >> DriverBindingSupported() return error.
>>>> >>
>>>> >> DriverBindingSupported() just read pci config header and judge the
>>>> >> class
>>>> >> code to see if it’s ehci or uhci.
>>>> >>
>>>> >>

[Adhyas Avasthi]

Jordan

Can you share specific details of your experiment? I am trying to make it
run now and am not successful using out of the box code components, so I am
working towards fixing the issue, if it exists.

To clarify, can you share the qemu command you can use to start a VM with
Ubuntu10.10 x86-64 ISO attached that can boot into the VM ? Did you have any
other specific changes in BIOS or qemu ?

I will appreciate any pointers in this regard.

[Adhyas Avasthi]

Alright, if I wait long enough (long means about 15 minutes), I can see the
graphics display from Ubuntu. Still a blank colored graphics screen with
nothing on it. I guess this is because I am running with the no-kvm option.
Perhaps the rest of Ubuntu will also come up if I give it enough time (like,
maybe over night) :-)

But such speed is just not acceptable for me to be able to use OVMF for any
VM booting work. Does anyone know why does OVMF not boot to even grub with
kvm enabled? If I enable kvm, I could not even see the grub screen in the
VM. I would like to fix it, so if you have any pointers, please let me know
and I can try to take a look into the code.

Thanks,
Adhyas

On Wed, Nov 10, 2010 at 5:58 PM, Adhyas Avasthi <***@gmail.com> wrote:

> Jordan
>
> Can you share specific details of your experiment? I am trying to make it
> run now and am not successful using out of the box code components, so I am
> working towards fixing the issue, if it exists.
>
> To clarify, can you share the qemu command you can use to start a VM with
> Ubuntu10.10 x86-64 ISO attached that can boot into the VM ? Did you have any
> other specific changes in BIOS or qemu ?
>
> I will appreciate any pointers in this regard.
>

[Adhyas Avasthi]

Some more debug find. It seems that the Grub2 bootloader in Ubuntu 10.10
crashes the system soon after it is started with -enable-kvm option.
Here is the output from serial log:

!!!! X64 Exception Type - 000000000000000D !!!!
ExceptionData - 0000000000000000
RIP - 000000001FFA937A, RFL - 0000000000010206
RAX - 000000001FF351C0, RCX - 0000000000000000, RDX - 000000001FFBB1B0
RBX - 000000001FF35400, RSP - 000000001FF97540, RBP - 000000001FFBB1B0
RSI - 000000001FFBB1F0, RDI - 000000001FF35200
R8 - 0000000000000000, R9 - 000000001FFBB1EF, R10 - 000000001E5E1728
R11 - 000000001FF973D8, R12 - 000000001FFB6810, R13 - 0000000000000070
R14 - 000000001DDBAFFF, R15 - 0000000000000060
CS - 0028, DS - 0008, ES - 0008, FS - 0008, GS - 0008, SS - 0008
GDT - 000000001FF1CE98; 003F, IDT - 000000001FE88BC0; 0FFF
LDT - 0000000000000000, TR - 0000000000000000
CR0 - 0000000080000023, CR2 - 0000000000000000, CR3 - 000000001FF36000
CR4 - 0000000000000668, CR8 - 0000000000000000
DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400

Trying to get Grub2 sources to identify the root cause. Any pointers are
welcome.

Thanks,
Adhyas


On Wed, Nov 10, 2010 at 6:27 PM, Adhyas Avasthi <***@gmail.com> wrote:

> Alright, if I wait long enough (long means about 15 minutes), I can see the
> graphics display from Ubuntu. Still a blank colored graphics screen with
> nothing on it. I guess this is because I am running with the no-kvm option.
> Perhaps the rest of Ubuntu will also come up if I give it enough time (like,
> maybe over night) :-)
>
> But such speed is just not acceptable for me to be able to use OVMF for any
> VM booting work. Does anyone know why does OVMF not boot to even grub with
> kvm enabled? If I enable kvm, I could not even see the grub screen in the
> VM. I would like to fix it, so if you have any pointers, please let me know
> and I can try to take a look into the code.
>
> Thanks,
> Adhyas
>
>
> On Wed, Nov 10, 2010 at 5:58 PM, Adhyas Avasthi <***@gmail.com> wrote:
>
>> Jordan
>>
>> Can you share specific details of your experiment? I am trying to make it
>> run now and am not successful using out of the box code components, so I am
>> working towards fixing the issue, if it exists.
>>
>> To clarify, can you share the qemu command you can use to start a VM with
>> Ubuntu10.10 x86-64 ISO attached that can boot into the VM ? Did you have any
>> other specific changes in BIOS or qemu ?
>>
>> I will appreciate any pointers in this regard.
>>

[Jordan Justen]

[Adhyas Avasthi]

Yes, that is my find as well. I was surprised to see the long delay
without kvm as well and perhaps there might be something else going on
there. I don't have a clue what might it be to make it this slow. I
have used 10.10 x64 on legacy BIOS in a VM, and that works just fine
(with kvm, that is). Let me try that without kvm on legacy BIOS to
compare results.
Also, Grub2 community is not very interested to work with me in
resolving this issue, they just want to write it off as a kvm issue,
so no help there :-)

I will give it a day or two more, then see if I should rather move to
eLilo and SUSE.
I do need to boot a Linux OS on pure EFI in a VM.

Thanks,
Adhyas

On Wed, Nov 10, 2010 at 11:02 PM, Jordan Justen <***@gmail.com> wrote:
> Adhyas,
>
> I got the same results as you.  (at least 5 minutes for a boot)
>
> I also noted that the slow boot speed on Ubuntu 10.10 is reproducible
> with -no-kvm and a legacy boot of qemu.  I am pretty surprised that
> kvm would make that much of a difference (20 seconds vs. maybe 10
> minutes), so I suspect something else might be going wrong.
>
> I have not had a chance to investigate the crash with OVMF when kvm is
> enabled, but OVMF can boot to the shell at least with kvm enabled.
>
> -Jordan
>
> On Wed, Nov 10, 2010 at 19:26, Adhyas Avasthi <***@gmail.com> wrote:
>> Some more debug find. It seems that the Grub2 bootloader in Ubuntu 10.10
>> crashes the system soon after it is started with -enable-kvm option.
>> Here is the output from serial log:
>>
>> !!!! X64 Exception Type - 000000000000000D !!!!
>> ExceptionData - 0000000000000000
>> RIP - 000000001FFA937A, RFL - 0000000000010206
>> RAX - 000000001FF351C0, RCX - 0000000000000000, RDX - 000000001FFBB1B0
>> RBX - 000000001FF35400, RSP - 000000001FF97540, RBP - 000000001FFBB1B0
>> RSI - 000000001FFBB1F0, RDI - 000000001FF35200
>> R8  - 0000000000000000, R9  - 000000001FFBB1EF, R10 - 000000001E5E1728
>> R11 - 000000001FF973D8, R12 - 000000001FFB6810, R13 - 0000000000000070
>> R14 - 000000001DDBAFFF, R15 - 0000000000000060
>> CS  - 0028, DS  - 0008, ES  - 0008, FS  - 0008, GS  - 0008, SS  - 0008
>> GDT - 000000001FF1CE98; 003F,                   IDT - 000000001FE88BC0; 0FFF
>> LDT - 0000000000000000, TR  - 0000000000000000
>> CR0 - 0000000080000023, CR2 - 0000000000000000, CR3 - 000000001FF36000
>> CR4 - 0000000000000668, CR8 - 0000000000000000
>> DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
>> DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
>>
>> Trying to get Grub2 sources to identify the root cause. Any pointers are
>> welcome.
>>
>> Thanks,
>> Adhyas
>>
>>
>> On Wed, Nov 10, 2010 at 6:27 PM, Adhyas Avasthi <***@gmail.com> wrote:
>>>
>>> Alright, if I wait long enough (long means about 15 minutes), I can see
>>> the graphics display from Ubuntu. Still a blank colored graphics screen with
>>> nothing on it. I guess this is because I am running with the no-kvm option.
>>> Perhaps the rest of Ubuntu will also come up if I give it enough time (like,
>>> maybe over night) :-)
>>>
>>> But such speed is just not acceptable for me to be able to use OVMF for
>>> any VM booting work. Does anyone know why does OVMF not boot to even grub
>>> with kvm enabled? If I enable kvm, I could not even see the grub screen in
>>> the VM. I would like to fix it, so if you have any pointers, please let me
>>> know and I can try to take a look into the code.
>>>
>>> Thanks,
>>> Adhyas
>>>
>>> On Wed, Nov 10, 2010 at 5:58 PM, Adhyas Avasthi <***@gmail.com> wrote:
>>>>
>>>> Jordan
>>>>
>>>> Can you share specific details of your experiment? I am trying to make it
>>>> run now and am not successful using out of the box code components, so I am
>>>> working towards fixing the issue, if it exists.
>>>>
>>>> To clarify, can you share the qemu command you can use to start a VM with
>>>> Ubuntu10.10 x86-64 ISO attached that can boot into the VM ? Did you have any
>>>> other specific changes in BIOS or qemu ?
>>>>
>>>> I will appreciate any pointers in this regard.
>>>>
>>>>

[Adhyas Avasthi]

eLilo looks much better. It has both initrd and kernel images as part of the
Boot FAT partition and loads them successfully. I also get the
ExitBootServices call from the loader. Soon after that my VM reboots, so I
cannot boot to the OS. Not sure where the issue resides though.

Thanks,
Adhyas


On Thu, Nov 11, 2010 at 8:13 AM, Adhyas Avasthi <***@gmail.com> wrote:

> Yes, that is my find as well. I was surprised to see the long delay
> without kvm as well and perhaps there might be something else going on
> there. I don't have a clue what might it be to make it this slow. I
> have used 10.10 x64 on legacy BIOS in a VM, and that works just fine
> (with kvm, that is). Let me try that without kvm on legacy BIOS to
> compare results.
> Also, Grub2 community is not very interested to work with me in
> resolving this issue, they just want to write it off as a kvm issue,
> so no help there :-)
>
> I will give it a day or two more, then see if I should rather move to
> eLilo and SUSE.
> I do need to boot a Linux OS on pure EFI in a VM.
>
> Thanks,
> Adhyas
>
> On Wed, Nov 10, 2010 at 11:02 PM, Jordan Justen <***@gmail.com>
> wrote:
> > Adhyas,
> >
> > I got the same results as you. (at least 5 minutes for a boot)
> >
> > I also noted that the slow boot speed on Ubuntu 10.10 is reproducible
> > with -no-kvm and a legacy boot of qemu. I am pretty surprised that
> > kvm would make that much of a difference (20 seconds vs. maybe 10
> > minutes), so I suspect something else might be going wrong.
> >
> > I have not had a chance to investigate the crash with OVMF when kvm is
> > enabled, but OVMF can boot to the shell at least with kvm enabled.
> >
> > -Jordan
> >
> > On Wed, Nov 10, 2010 at 19:26, Adhyas Avasthi <***@gmail.com> wrote:
> >> Some more debug find. It seems that the Grub2 bootloader in Ubuntu 10.10
> >> crashes the system soon after it is started with -enable-kvm option.
> >> Here is the output from serial log:
> >>
> >> !!!! X64 Exception Type - 000000000000000D !!!!
> >> ExceptionData - 0000000000000000
> >> RIP - 000000001FFA937A, RFL - 0000000000010206
> >> RAX - 000000001FF351C0, RCX - 0000000000000000, RDX - 000000001FFBB1B0
> >> RBX - 000000001FF35400, RSP - 000000001FF97540, RBP - 000000001FFBB1B0
> >> RSI - 000000001FFBB1F0, RDI - 000000001FF35200
> >> R8 - 0000000000000000, R9 - 000000001FFBB1EF, R10 - 000000001E5E1728
> >> R11 - 000000001FF973D8, R12 - 000000001FFB6810, R13 - 0000000000000070
> >> R14 - 000000001DDBAFFF, R15 - 0000000000000060
> >> CS - 0028, DS - 0008, ES - 0008, FS - 0008, GS - 0008, SS - 0008
> >> GDT - 000000001FF1CE98; 003F, IDT - 000000001FE88BC0;
> 0FFF
> >> LDT - 0000000000000000, TR - 0000000000000000
> >> CR0 - 0000000080000023, CR2 - 0000000000000000, CR3 - 000000001FF36000
> >> CR4 - 0000000000000668, CR8 - 0000000000000000
> >> DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
> >> DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
> >>
> >> Trying to get Grub2 sources to identify the root cause. Any pointers are
> >> welcome.
> >>
> >> Thanks,
> >> Adhyas
> >>
> >>
> >> On Wed, Nov 10, 2010 at 6:27 PM, Adhyas Avasthi <***@gmail.com>
> wrote:
> >>>
> >>> Alright, if I wait long enough (long means about 15 minutes), I can see
> >>> the graphics display from Ubuntu. Still a blank colored graphics screen
> with
> >>> nothing on it. I guess this is because I am running with the no-kvm
> option.
> >>> Perhaps the rest of Ubuntu will also come up if I give it enough time
> (like,
> >>> maybe over night) :-)
> >>>
> >>> But such speed is just not acceptable for me to be able to use OVMF for
> >>> any VM booting work. Does anyone know why does OVMF not boot to even
> grub
> >>> with kvm enabled? If I enable kvm, I could not even see the grub screen
> in
> >>> the VM. I would like to fix it, so if you have any pointers, please let
> me
> >>> know and I can try to take a look into the code.
> >>>
> >>> Thanks,
> >>> Adhyas
> >>>
> >>> On Wed, Nov 10, 2010 at 5:58 PM, Adhyas Avasthi <***@gmail.com>
> wrote:
> >>>>
> >>>> Jordan
> >>>>
> >>>> Can you share specific details of your experiment? I am trying to make
> it
> >>>> run now and am not successful using out of the box code components, so
> I am
> >>>> working towards fixing the issue, if it exists.
> >>>>
> >>>> To clarify, can you share the qemu command you can use to start a VM
> with
> >>>> Ubuntu10.10 x86-64 ISO attached that can boot into the VM ? Did you
> have any
> >>>> other specific changes in BIOS or qemu ?
> >>>>
> >>>> I will appreciate any pointers in this regard.
> >>>>

[Jordan Justen]

On Thu, Nov 11, 2010 at 11:37, Adhyas Avasthi <***@gmail.com> wrote:
> eLilo looks much better. It has both initrd and kernel images as part of the
> Boot FAT partition and loads them successfully. I also get the
> ExitBootServices call from the loader. Soon after that my VM reboots, so I
> cannot boot to the OS. Not sure where the issue resides though.

Try adding console=ttyS0,115200n8 to the kernel command line.
(Actually, I think console=ttyS0 should work fine on its own for
qemu.)

Then use '-serial file:serial.out' for qemu to capture the serial output.

-Jordan

[Adhyas Avasthi]

I could not get any kernel output by appending what you suggested.

More find. I debugged elilo to find out that elilo loads the kernel
just fine, and then it is the kernel that reboots my machine all the
time. Something funny is going on with the kernel start.
On further debugging, I found some more interesting stuff. Seems like
for openSUSE, they keep the kernel bzImage and initrd on the same boot
fat filesystem as the boot loader itself. A hex dump of the bzImage
shows that the start of the image is a jump to 0x7C00 (on EFI ??). And
elilo jumps to this instruction after loading the kernel. I think I
went into no-man's land after that.
Why would the kernel want to jump to 0x7C00 for an EFI Boot?

elilo had some commented out code that put some bytes at 7C00. I
uncommented the code in my build, but no progress. This code basically
moved me back into real mode and then tried to jump to startup.S of
the kernel itself. But still nothing really happened.

I guess the VM reboot is happening because of random code execution
leading me nowhere and is not intentional.

I am trying to get hold of the elilo guys now to discuss these issues with them.

- Adhyas

On Thu, Nov 11, 2010 at 1:05 PM, Jordan Justen <***@gmail.com> wrote:
> On Thu, Nov 11, 2010 at 11:37, Adhyas Avasthi <***@gmail.com> wrote:
>> eLilo looks much better. It has both initrd and kernel images as part of the
>> Boot FAT partition and loads them successfully. I also get the
>> ExitBootServices call from the loader. Soon after that my VM reboots, so I
>> cannot boot to the OS. Not sure where the issue resides though.
>
> Try adding console=ttyS0,115200n8 to the kernel command line.
> (Actually, I think console=ttyS0 should work fine on its own for
> qemu.)
>
> Then use '-serial file:serial.out' for qemu to capture the serial output.
>
> -Jordan
>
> ------------------------------------------------------------------------------
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> _______________________________________________
> edk2-devel mailing list
> edk2-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>



--
Adhyas
********************************************************************
Two types have compatible type if their types are the same.
    — ANSI C Standard, 3.1.2.6.
********************************************************************

[Adhyas Avasthi]

Looking at kernel sources, I guess the kernel just reboots to where we
are jumping into it from the boot loader. Did someone really test the
openSUSE efi boot ever?

>

[Adhyas Avasthi]

Alright, I think I have been able to root cause the issue in the case
of Grub Boot Loader with kvm enabled. This is a case of calling
convention issues between efi and gcc. While Grub has a call wrapper
assembly file that seems to do the right thing for the calling
convention required by efi, it does not work when kvm is enabled. The
assembly file does the right thing with kvm disabled (pure qemu
emulation).

With kvm enabled, the instructions (I assume) get executed on the real
host's cpu. I have no idea why that would mess up with the calling
convention. Does anyone have a pointer on what I can put in as a quick
hack to solve things. Here is the sample wrapper function from grub's
source code that gets invoked before making the call to efi.

/*
* x86_64 uses registry to pass parameters. Unfortunately, gcc and efi use
* different call conversion, so we need to do some conversion.
*
* gcc:
* %rdi, %esi, %rdx, %rcx, %r8, %r9, 8(%rsp), 16(%rsp), ...
*
* efi:
* %rcx, %rdx, %r8, %r9, 32(%rsp), 40(%rsp), 48(%rsp), ...
*
*/

FUNCTION(efi_wrap_4)
subq $40, %rsp
mov %r8, %r9
mov %rcx, %r8
mov %rsi, %rcx
call *%rdi
addq $40, %rsp
ret

Thanks,
Adhyas

On Fri, Nov 12, 2010 at 3:51 PM, Adhyas Avasthi <***@gmail.com> wrote:
> Looking at kernel sources, I guess the kernel just reboots to where we
> are jumping into it from the boot loader. Did someone really test the
> openSUSE efi boot ever?
>
>

[Jordan Justen]

Adhyas,

How easy would it be to isolate the instance where the exception
happens at the outer level?

For instance, could you add this:

FUNCTION(efi_wrap_4_with_hang)
subq $40, %rsp
mov %r8, %r9
mov %rcx, %r8
mov %rsi, %rcx
efi_wrap_4_hang:
jmp efi_wrap_4_hang
call *%rdi
addq $40, %rsp
ret

Then change the outer level code to use efi_wrap_4_with_hang instead,
and compare the environment in the working and failing cases after the
hang is encountered?

What UEFI function is being called? We might be able to add some
serial messages to the OVMF side of the call, if it gets to the
firmware code.

-Jordan

On Sat, Nov 13, 2010 at 15:20, Adhyas Avasthi <***@gmail.com> wrote:
> Alright, I think I have been able to root cause the issue in the case
> of Grub Boot Loader with kvm enabled. This is a case of calling
> convention issues between efi and gcc. While Grub has a call wrapper
> assembly file that seems to do the right thing for the calling
> convention required by efi, it does not work when kvm is enabled. The
> assembly file does the right thing with kvm disabled (pure qemu
> emulation).
>
> With kvm enabled, the instructions (I assume) get executed on the real
> host's cpu. I have no idea why that would mess up with the calling
> convention. Does anyone have a pointer on what I can put in as a quick
> hack to solve things. Here is the sample wrapper function from grub's
> source code that gets invoked before making the call to efi.
>
> /*
>  * x86_64 uses registry to pass parameters. Unfortunately, gcc and efi use
>  * different call conversion, so we need to do some conversion.
>  *
>  * gcc:
>  *   %rdi,  %esi,  %rdx,  %rcx, %r8, %r9, 8(%rsp), 16(%rsp), ...
>  *
>  * efi:
>  *   %rcx,  %rdx,  %r8,  %r9,  32(%rsp), 40(%rsp), 48(%rsp), ...
>  *
>  */
>
> FUNCTION(efi_wrap_4)
>        subq $40, %rsp
>        mov %r8, %r9
>        mov %rcx, %r8
>        mov %rsi, %rcx
>        call *%rdi
>        addq $40, %rsp
>        ret
>
> Thanks,
> Adhyas
>
> On Fri, Nov 12, 2010 at 3:51 PM, Adhyas Avasthi <***@gmail.com> wrote:
>> Looking at kernel sources, I guess the kernel just reboots to where we
>> are jumping into it from the boot loader. Did someone really test the
>> openSUSE efi boot ever?
>>
>>

[Adhyas Avasthi]

Let me try what you suggest. The other problem is that somehow my
remote gdb connection to qemu does not work. Perhaps this is a 64-bit
debug specific issue in qemu or something with my environment. Just
make things harder to debug as I am putting hacks in the qemu code
itself to print debug information when I want it (using my own debug
port that I have created). Nonetheless, let me see if I can find the
diff of the two states.

I am calling AllocatePages of Boot Services. The first EFI System Call
made by Grub2.

Thanks,
Adhyas

On Sat, Nov 13, 2010 at 4:20 PM, Jordan Justen <***@gmail.com> wrote:
> Adhyas,
>
> How easy would it be to isolate the instance where the exception
> happens at the outer level?
>
> For instance, could you add this:
>
>  FUNCTION(efi_wrap_4_with_hang)
>        subq $40, %rsp
>        mov %r8, %r9
>        mov %rcx, %r8
>        mov %rsi, %rcx
> efi_wrap_4_hang:
>        jmp   efi_wrap_4_hang
>        call *%rdi
>        addq $40, %rsp
>        ret
>
> Then change the outer level code to use efi_wrap_4_with_hang instead,
> and compare the environment in the working and failing cases after the
> hang is encountered?
>
> What UEFI function is being called?  We might be able to add some
> serial messages to the OVMF side of the call, if it gets to the
> firmware code.
>
> -Jordan
>
> On Sat, Nov 13, 2010 at 15:20, Adhyas Avasthi <***@gmail.com> wrote:
>> Alright, I think I have been able to root cause the issue in the case
>> of Grub Boot Loader with kvm enabled. This is a case of calling
>> convention issues between efi and gcc. While Grub has a call wrapper
>> assembly file that seems to do the right thing for the calling
>> convention required by efi, it does not work when kvm is enabled. The
>> assembly file does the right thing with kvm disabled (pure qemu
>> emulation).
>>
>> With kvm enabled, the instructions (I assume) get executed on the real
>> host's cpu. I have no idea why that would mess up with the calling
>> convention. Does anyone have a pointer on what I can put in as a quick
>> hack to solve things. Here is the sample wrapper function from grub's
>> source code that gets invoked before making the call to efi.
>>
>> /*
>>  * x86_64 uses registry to pass parameters. Unfortunately, gcc and efi use
>>  * different call conversion, so we need to do some conversion.
>>  *
>>  * gcc:
>>  *   %rdi,  %esi,  %rdx,  %rcx, %r8, %r9, 8(%rsp), 16(%rsp), ...
>>  *
>>  * efi:
>>  *   %rcx,  %rdx,  %r8,  %r9,  32(%rsp), 40(%rsp), 48(%rsp), ...
>>  *
>>  */
>>
>> FUNCTION(efi_wrap_4)
>>        subq $40, %rsp
>>        mov %r8, %r9
>>        mov %rcx, %r8
>>        mov %rsi, %rcx
>>        call *%rdi
>>        addq $40, %rsp
>>        ret
>>
>> Thanks,
>> Adhyas
>>
>> On Fri, Nov 12, 2010 at 3:51 PM, Adhyas Avasthi <***@gmail.com> wrote:
>>> Looking at kernel sources, I guess the kernel just reboots to where we
>>> are jumping into it from the boot loader. Did someone really test the
>>> openSUSE efi boot ever?
>>>
>>>

[Adhyas Avasthi]

Hi Jordan

Here is the info you asked for. I just produced it (am analyzing it as
well as we speak). Sending upfront:

The non-working case (with kvm enabled), register layout at hang:

(qemu) info registers
RAX=000000001ff34f18 RBX=0000000000000006 RCX=0000000000000000
RDX=0000000000000002
RSI=0000000000000000 RDI=000000001ff9a504 RBP=000000001d9a4285
RSP=000000001ff97708
R8 =0000000000000006 R9 =000000001ff97740 R10=0000000000000010
R11=0000000000000009
R12=000000001ffb5960 R13=000000001ff97740 R14=0000000000000000
R15=000000001d99d750
RIP=000000001d99d75d RFL=00000212 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0008 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA]
CS =0028 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA]
SS =0008 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA]
DS =0008 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA]
FS =0008 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA]
GS =0008 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA]
LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
GDT= 000000001ff1ce98 0000003f
IDT= 000000001fe88bc0 00000fff
CR0=80000023 CR2=0000000000000000 CR3=000000001ff36000 CR4=00000668
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000
DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000500
FCW=027f FSW=0000 [ST=0] FTW=00 MXCSR=00000000
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000
XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000
XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000
XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000

The working case (with kvm disabled), register layout at hang:
(qemu) info registers
RAX=000000001ff34f18 RBX=0000000000000006 RCX=0000000000000000
RDX=0000000000000002
RSI=0000000000000000 RDI=000000001ff9a504 RBP=000000001d9a4285
RSP=000000001ff97708
R8 =0000000000000006 R9 =000000001ff97740 R10=0000000000000010
R11=0000000000000009
R12=000000001ffb5960 R13=000000001ff97740 R14=0000000000000000
R15=000000001d99d750
RIP=000000001d99d75d RFL=00000212 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA]
CS =0028 0000000000000000 ffffffff 00af9b00 DPL=0 CS64 [-RA]
SS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA]
FS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
GDT= 000000001ff1ce98 0000003f
IDT= 000000001fe88bc0 00000fff
CR0=80000033 CR2=0000000000000000 CR3=000000001ff36000 CR4=00000668
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000
DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000500
FCW=027f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000
XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000
XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000
XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000

I am making the call as follows:
efi_call_4 (b->allocate_pages, type, GRUB_EFI_LOADER_DATA, pages, &address);

#define efi_call_4(func, a, b, c, d) \
efi_wrap_4(func, (grub_uint64_t) a, (grub_uint64_t) b, (grub_uint64_t) c, \
(grub_uint64_t) d)

And the target is:
EFI_STATUS
EFIAPI
CoreAllocatePages (
IN EFI_ALLOCATE_TYPE Type,
IN EFI_MEMORY_TYPE MemoryType,
IN UINTN NumberOfPages,
IN OUT EFI_PHYSICAL_ADDRESS *Memory
)

Thanks,
Adhyas

On Sat, Nov 13, 2010 at 4:20 PM, Jordan Justen <***@gmail.com> wrote:
> Adhyas,
>
> How easy would it be to isolate the instance where the exception
> happens at the outer level?
>
> For instance, could you add this:
>
>  FUNCTION(efi_wrap_4_with_hang)
>        subq $40, %rsp
>        mov %r8, %r9
>        mov %rcx, %r8
>        mov %rsi, %rcx
> efi_wrap_4_hang:
>        jmp   efi_wrap_4_hang
>        call *%rdi
>        addq $40, %rsp
>        ret
>
> Then change the outer level code to use efi_wrap_4_with_hang instead,
> and compare the environment in the working and failing cases after the
> hang is encountered?
>
> What UEFI function is being called?  We might be able to add some
> serial messages to the OVMF side of the call, if it gets to the
> firmware code.
>
> -Jordan
>
> On Sat, Nov 13, 2010 at 15:20, Adhyas Avasthi <***@gmail.com> wrote:
>> Alright, I think I have been able to root cause the issue in the case
>> of Grub Boot Loader with kvm enabled. This is a case of calling
>> convention issues between efi and gcc. While Grub has a call wrapper
>> assembly file that seems to do the right thing for the calling
>> convention required by efi, it does not work when kvm is enabled. The
>> assembly file does the right thing with kvm disabled (pure qemu
>> emulation).
>>
>> With kvm enabled, the instructions (I assume) get executed on the real
>> host's cpu. I have no idea why that would mess up with the calling
>> convention. Does anyone have a pointer on what I can put in as a quick
>> hack to solve things. Here is the sample wrapper function from grub's
>> source code that gets invoked before making the call to efi.
>>
>> /*
>>  * x86_64 uses registry to pass parameters. Unfortunately, gcc and efi use
>>  * different call conversion, so we need to do some conversion.
>>  *
>>  * gcc:
>>  *   %rdi,  %esi,  %rdx,  %rcx, %r8, %r9, 8(%rsp), 16(%rsp), ...
>>  *
>>  * efi:
>>  *   %rcx,  %rdx,  %r8,  %r9,  32(%rsp), 40(%rsp), 48(%rsp), ...
>>  *
>>  */
>>
>> FUNCTION(efi_wrap_4)
>>        subq $40, %rsp
>>        mov %r8, %r9
>>        mov %rcx, %r8
>>        mov %rsi, %rcx
>>        call *%rdi
>>        addq $40, %rsp
>>        ret
>>
>> Thanks,
>> Adhyas
>>
>> On Fri, Nov 12, 2010 at 3:51 PM, Adhyas Avasthi <***@gmail.com> wrote:
>>> Looking at kernel sources, I guess the kernel just reboots to where we
>>> are jumping into it from the boot loader. Did someone really test the
>>> openSUSE efi boot ever?
>>>
>>>

[Andrew Fish]

Looks like there are slight differences in processor mode, due to virtualization.

I noticed from the KVM main page (http://www.linux-kvm.org/page/Main_Page) that QEMU modifications are required to support KVM are you using the right version of QEMU?

The other thing to check is that the EFI boot services space is properly identity mapped in the page tables (virtualized and physical).

Andrew Fish





On Nov 13, 2010, at 10:36 PM, Adhyas Avasthi wrote:

> (qemu) info registers
> RAX=000000001ff34f18 RBX=0000000000000006 RCX=0000000000000000
> RDX=0000000000000002
> RSI=0000000000000000 RDI=000000001ff9a504 RBP=000000001d9a4285
> RSP=000000001ff97708
> R8 =0000000000000006 R9 =000000001ff97740 R10=0000000000000010
> R11=0000000000000009
> R12=000000001ffb5960 R13=000000001ff97740 R14=0000000000000000
> R15=000000001d99d750
> RIP=000000001d99d75d RFL=00000212 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA]
> CS =0028 0000000000000000 ffffffff 00af9b00 DPL=0 CS64 [-RA]
> SS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA]
> DS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA]
> FS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA]
> GS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA]
> LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
> TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
> GDT= 000000001ff1ce98 0000003f
> IDT= 000000001fe88bc0 00000fff
> CR0=80000033 CR2=0000000000000000 CR3=000000001ff36000 CR4=00000668
> DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000
> DR3=0000000000000000
> DR6=00000000ffff0ff0 DR7=0000000000000400
> EFER=0000000000000500
> FCW=027f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
> FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
> FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
> FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
> FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
> XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
> XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
> XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
> XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
> XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000
> XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000
> XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000
> XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000

[Jordan Justen]

On Sun, Nov 14, 2010 at 08:14, Andrew Fish <***@apple.com> wrote:
> I noticed from the KVM main page (http://www.linux-kvm.org/page/Main_Page) that QEMU modifications are required to support KVM are you using the right version of QEMU?

The user-mode portion of kvm (the modified qemu part) has mostly
merged back into qemu at this point, so I think the text on that page
is pretty much obsolete.

For instance, on Ubuntu, both the qemu or kvm packages are really just
another name for the qemu-kvm package.

-Jordan

[Adhyas Avasthi]

>

[Adhyas Avasthi]

Perhaps to make it work, I can define the reverse wrapper within EFI
BIOS (just to make sure that portion works). Maybe I can define a
wrapper function within EFI that I can call instead to convert the
parameters to EFI style.

That would require me to append to the SystemTable or BootServices and
then perhaps use some code from what Andrew pointed out. Let me see
how that goes. At this point, however, I am just short of options.
Also raised this issue with the kvm mailing list but they are not too
interested as it may not be high priority to them. I can't imagine
that I am the only person hitting this issue and if this issue is
purely EFI specific.

Thanks,
Adhyas

On Sun, Nov 14, 2010 at 11:53 AM, Adhyas Avasthi <***@gmail.com> wrote:
>

[Jordan Justen]

Adhyas,

I was trying to track this down from the OVMF side by updating
CoreAllocatePages to send messages to the serial port. (See attached
patch.)

But, that seems to indicate that CoreAllocatePages returns successfully:
> Booting EFI DVD/CDROM
> BlockSize : 2048
> LastBlock : 56DFC
> BlockSize : 2048
> LastBlock : 3
> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 1E16DE40
> AllocatePoolPages: Type=0x0, MemType=0x1, NumPages=0x57, MemPtr=0x1E16DF08
> AllocatePoolPages -> Success
> Loading driver at 0x0001DF23000 EntryPoint=0x0001DF23400
> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 1E18C018
> !!!! X64 Exception Type - 000000000000000D !!!!

The other interpretation could be that the gasket/wrapper code never
successfully makes it into the CoreAllocatePages code in the failing
case.

I'm testing with the Ubuntu 10.10 amd64 release ISO...

-Jordan

On Sun, Nov 14, 2010 at 12:33, Adhyas Avasthi <***@gmail.com> wrote:
> Perhaps to make it work, I can define the reverse wrapper within EFI
> BIOS (just to make sure that portion works). Maybe I can define a
> wrapper function within EFI that I can call instead to convert the
> parameters to EFI style.
>
> That would require me to append to the SystemTable or BootServices and
> then perhaps use some code from what Andrew pointed out. Let me see
> how that goes. At this point, however, I am just short of options.
> Also raised this issue with the kvm mailing list but they are not too
> interested as it may not be high priority to them. I can't imagine
> that I am the only person hitting this issue and if this issue is
> purely EFI specific.
>
> Thanks,
> Adhyas
>
> On Sun, Nov 14, 2010 at 11:53 AM, Adhyas Avasthi <***@gmail.com> wrote:

[Adhyas Avasthi]

Hi Jordan

Thanks for pointing it out. I always had the similar debug statements
in CoreAllocatePages but completely missed seeing them till you
pointed out. Yes, you are right, the call is made properly but it
never returns back it seems. I think the crash is happening from
within CoreConvertPages as per my debug statements. Let me see where
the problem is. Thanks again for the pointer.

Thanks,
Adhyas

On Sun, Nov 14, 2010 at 1:09 PM, Jordan Justen <***@gmail.com> wrote:
> Adhyas,
>
> I was trying to track this down from the OVMF side by updating
> CoreAllocatePages to send messages to the serial port.  (See attached
> patch.)
>
> But, that seems to indicate that CoreAllocatePages returns successfully:
>> Booting EFI DVD/CDROM
>>  BlockSize : 2048
>>  LastBlock : 56DFC
>>  BlockSize : 2048
>>  LastBlock : 3
>> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 1E16DE40
>> AllocatePoolPages: Type=0x0, MemType=0x1, NumPages=0x57, MemPtr=0x1E16DF08
>> AllocatePoolPages -> Success
>> Loading driver at 0x0001DF23000 EntryPoint=0x0001DF23400
>> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 1E18C018
>> !!!! X64 Exception Type - 000000000000000D !!!!
>
> The other interpretation could be that the gasket/wrapper code never
> successfully makes it into the CoreAllocatePages code in the failing
> case.
>
> I'm testing with the Ubuntu 10.10 amd64 release ISO...
>
> -Jordan
>
> On Sun, Nov 14, 2010 at 12:33, Adhyas Avasthi <***@gmail.com> wrote:
>> Perhaps to make it work, I can define the reverse wrapper within EFI
>> BIOS (just to make sure that portion works). Maybe I can define a
>> wrapper function within EFI that I can call instead to convert the
>> parameters to EFI style.
>>
>> That would require me to append to the SystemTable or BootServices and
>> then perhaps use some code from what Andrew pointed out. Let me see
>> how that goes. At this point, however, I am just short of options.
>> Also raised this issue with the kvm mailing list but they are not too
>> interested as it may not be high priority to them. I can't imagine
>> that I am the only person hitting this issue and if this issue is
>> purely EFI specific.
>>
>> Thanks,
>> Adhyas
>>
>> On Sun, Nov 14, 2010 at 11:53 AM, Adhyas Avasthi <***@gmail.com> wrote:
>>>

[Jordan Justen]

Adhyas,

I've been able to boot the Ubuntu 10.10 x86-64 Live CD via UEFI with kvm.

The exceptions seem to be caused by something grub is doing that
causes mmx register accesses to cause an exception. So, to fix this:

1. Update Conf/tools_def.txt. Find the line starting with:
DEFINE GCC44_ALL_CC_FLAGS
and add this to the end:
-mno-mmx -mno-sse

2. Modify OvmfPkg/OvmfPkgX64.dsc:
Replace all instances of:
BaseMemoryLib|MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf
with:
BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf

-Jordan

On Sun, Nov 14, 2010 at 14:05, Adhyas Avasthi <***@gmail.com> wrote:
> Hi Jordan
>
> Thanks for pointing it out. I always had the similar debug statements
> in CoreAllocatePages but completely missed seeing them till you
> pointed out. Yes, you are right, the call is made properly but it
> never returns back it seems. I think the crash is happening from
> within CoreConvertPages as per my debug statements. Let me see where
> the problem is. Thanks again for the pointer.
>
> Thanks,
> Adhyas
>
> On Sun, Nov 14, 2010 at 1:09 PM, Jordan Justen <***@gmail.com> wrote:
>> Adhyas,
>>
>> I was trying to track this down from the OVMF side by updating
>> CoreAllocatePages to send messages to the serial port.  (See attached
>> patch.)
>>
>> But, that seems to indicate that CoreAllocatePages returns successfully:
>>> Booting EFI DVD/CDROM
>>>  BlockSize : 2048
>>>  LastBlock : 56DFC
>>>  BlockSize : 2048
>>>  LastBlock : 3
>>> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 1E16DE40
>>> AllocatePoolPages: Type=0x0, MemType=0x1, NumPages=0x57, MemPtr=0x1E16DF08
>>> AllocatePoolPages -> Success
>>> Loading driver at 0x0001DF23000 EntryPoint=0x0001DF23400
>>> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 1E18C018
>>> !!!! X64 Exception Type - 000000000000000D !!!!
>>
>> The other interpretation could be that the gasket/wrapper code never
>> successfully makes it into the CoreAllocatePages code in the failing
>> case.
>>
>> I'm testing with the Ubuntu 10.10 amd64 release ISO...
>>
>> -Jordan
>>
>> On Sun, Nov 14, 2010 at 12:33, Adhyas Avasthi <***@gmail.com> wrote:
>>> Perhaps to make it work, I can define the reverse wrapper within EFI
>>> BIOS (just to make sure that portion works). Maybe I can define a
>>> wrapper function within EFI that I can call instead to convert the
>>> parameters to EFI style.
>>>
>>> That would require me to append to the SystemTable or BootServices and
>>> then perhaps use some code from what Andrew pointed out. Let me see
>>> how that goes. At this point, however, I am just short of options.
>>> Also raised this issue with the kvm mailing list but they are not too
>>> interested as it may not be high priority to them. I can't imagine
>>> that I am the only person hitting this issue and if this issue is
>>> purely EFI specific.
>>>
>>> Thanks,
>>> Adhyas
>>>
>>> On Sun, Nov 14, 2010 at 11:53 AM, Adhyas Avasthi <***@gmail.com> wrote:
>>>>

[Adhyas Avasthi]

Hi Jordan

Thanks for the pointers. I was able to boot to Ubuntu Live CD as well.
Will try installing now.
The boot loader is awfully slow, however. It takes me about half a
minute (approximately) before I select the boot method from the boot
loader screen and I get the ExitBootServices call. The OS is
relatively faster though.

Let me try installing Ubuntu now. Thanks again for the help.
I will try elilo when I get time a little bit later, now.

- Adhyas

On Sun, Nov 14, 2010 at 8:47 PM, Jordan Justen <***@gmail.com> wrote:
> Adhyas,
>
> I've been able to boot the Ubuntu 10.10 x86-64 Live CD via UEFI with kvm.
>
> The exceptions seem to be caused by something grub is doing that
> causes mmx register accesses to cause an exception.  So, to fix this:
>
> 1. Update Conf/tools_def.txt.  Find the line starting with:
> DEFINE GCC44_ALL_CC_FLAGS
> and add this to the end:
>  -mno-mmx -mno-sse
>
> 2. Modify OvmfPkg/OvmfPkgX64.dsc:
> Replace all instances of:
> BaseMemoryLib|MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf
> with:
> BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
>
> -Jordan
>
> On Sun, Nov 14, 2010 at 14:05, Adhyas Avasthi <***@gmail.com> wrote:
>> Hi Jordan
>>
>> Thanks for pointing it out. I always had the similar debug statements
>> in CoreAllocatePages but completely missed seeing them till you
>> pointed out. Yes, you are right, the call is made properly but it
>> never returns back it seems. I think the crash is happening from
>> within CoreConvertPages as per my debug statements. Let me see where
>> the problem is. Thanks again for the pointer.
>>
>> Thanks,
>> Adhyas
>>
>> On Sun, Nov 14, 2010 at 1:09 PM, Jordan Justen <***@gmail.com> wrote:
>>> Adhyas,
>>>
>>> I was trying to track this down from the OVMF side by updating
>>> CoreAllocatePages to send messages to the serial port.  (See attached
>>> patch.)
>>>
>>> But, that seems to indicate that CoreAllocatePages returns successfully:
>>>> Booting EFI DVD/CDROM
>>>>  BlockSize : 2048
>>>>  LastBlock : 56DFC
>>>>  BlockSize : 2048
>>>>  LastBlock : 3
>>>> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 1E16DE40
>>>> AllocatePoolPages: Type=0x0, MemType=0x1, NumPages=0x57, MemPtr=0x1E16DF08
>>>> AllocatePoolPages -> Success
>>>> Loading driver at 0x0001DF23000 EntryPoint=0x0001DF23400
>>>> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 1E18C018
>>>> !!!! X64 Exception Type - 000000000000000D !!!!
>>>
>>> The other interpretation could be that the gasket/wrapper code never
>>> successfully makes it into the CoreAllocatePages code in the failing
>>> case.
>>>
>>> I'm testing with the Ubuntu 10.10 amd64 release ISO...
>>>
>>> -Jordan
>>>
>>> On Sun, Nov 14, 2010 at 12:33, Adhyas Avasthi <***@gmail.com> wrote:
>>>> Perhaps to make it work, I can define the reverse wrapper within EFI
>>>> BIOS (just to make sure that portion works). Maybe I can define a
>>>> wrapper function within EFI that I can call instead to convert the
>>>> parameters to EFI style.
>>>>
>>>> That would require me to append to the SystemTable or BootServices and
>>>> then perhaps use some code from what Andrew pointed out. Let me see
>>>> how that goes. At this point, however, I am just short of options.
>>>> Also raised this issue with the kvm mailing list but they are not too
>>>> interested as it may not be high priority to them. I can't imagine
>>>> that I am the only person hitting this issue and if this issue is
>>>> purely EFI specific.
>>>>
>>>> Thanks,
>>>> Adhyas
>>>>
>>>> On Sun, Nov 14, 2010 at 11:53 AM, Adhyas Avasthi <***@gmail.com> wrote:
>>>>>

[Adhyas Avasthi]

BTW, What is the qemu command you are executing? I tried
./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 512 -serial
file:temp -L /home/adhyas/bios-binaries -cdrom
/home/adhyas/data/iso/ubuntu-10.10-desktop-amd64.iso -boot d -monitor
stdio

But I don't get the mouse to move within the VM. So I tried adding a
USB mouse instead with -usb -usbdevice mouse, but now the VM is taking
forever to respond. Were you able to get mouse? Anything specific you
used on the command prompt?

Thanks,
Adhyas

On Sun, Nov 14, 2010 at 11:18 PM, Adhyas Avasthi <***@gmail.com> wrote:
> Hi Jordan
>
> Thanks for the pointers. I was able to boot to Ubuntu Live CD as well.
> Will try installing now.
> The boot loader is awfully slow, however. It takes me about half a
> minute (approximately) before I select the boot method from the boot
> loader screen and I get the ExitBootServices call. The OS is
> relatively faster though.
>
> Let me try installing Ubuntu now. Thanks again for the help.
> I will try elilo when I get time a little bit later, now.
>
> - Adhyas
>
> On Sun, Nov 14, 2010 at 8:47 PM, Jordan Justen <***@gmail.com> wrote:
>> Adhyas,
>>
>> I've been able to boot the Ubuntu 10.10 x86-64 Live CD via UEFI with kvm.
>>
>> The exceptions seem to be caused by something grub is doing that
>> causes mmx register accesses to cause an exception.  So, to fix this:
>>
>> 1. Update Conf/tools_def.txt.  Find the line starting with:
>> DEFINE GCC44_ALL_CC_FLAGS
>> and add this to the end:
>>  -mno-mmx -mno-sse
>>
>> 2. Modify OvmfPkg/OvmfPkgX64.dsc:
>> Replace all instances of:
>> BaseMemoryLib|MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf
>> with:
>> BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
>>
>> -Jordan
>>
>> On Sun, Nov 14, 2010 at 14:05, Adhyas Avasthi <***@gmail.com> wrote:
>>> Hi Jordan
>>>
>>> Thanks for pointing it out. I always had the similar debug statements
>>> in CoreAllocatePages but completely missed seeing them till you
>>> pointed out. Yes, you are right, the call is made properly but it
>>> never returns back it seems. I think the crash is happening from
>>> within CoreConvertPages as per my debug statements. Let me see where
>>> the problem is. Thanks again for the pointer.
>>>
>>> Thanks,
>>> Adhyas
>>>
>>> On Sun, Nov 14, 2010 at 1:09 PM, Jordan Justen <***@gmail.com> wrote:
>>>> Adhyas,
>>>>
>>>> I was trying to track this down from the OVMF side by updating
>>>> CoreAllocatePages to send messages to the serial port.  (See attached
>>>> patch.)
>>>>
>>>> But, that seems to indicate that CoreAllocatePages returns successfully:
>>>>> Booting EFI DVD/CDROM
>>>>>  BlockSize : 2048
>>>>>  LastBlock : 56DFC
>>>>>  BlockSize : 2048
>>>>>  LastBlock : 3
>>>>> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 1E16DE40
>>>>> AllocatePoolPages: Type=0x0, MemType=0x1, NumPages=0x57, MemPtr=0x1E16DF08
>>>>> AllocatePoolPages -> Success
>>>>> Loading driver at 0x0001DF23000 EntryPoint=0x0001DF23400
>>>>> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 1E18C018
>>>>> !!!! X64 Exception Type - 000000000000000D !!!!
>>>>
>>>> The other interpretation could be that the gasket/wrapper code never
>>>> successfully makes it into the CoreAllocatePages code in the failing
>>>> case.
>>>>
>>>> I'm testing with the Ubuntu 10.10 amd64 release ISO...
>>>>
>>>> -Jordan
>>>>
>>>> On Sun, Nov 14, 2010 at 12:33, Adhyas Avasthi <***@gmail.com> wrote:
>>>>> Perhaps to make it work, I can define the reverse wrapper within EFI
>>>>> BIOS (just to make sure that portion works). Maybe I can define a
>>>>> wrapper function within EFI that I can call instead to convert the
>>>>> parameters to EFI style.
>>>>>
>>>>> That would require me to append to the SystemTable or BootServices and
>>>>> then perhaps use some code from what Andrew pointed out. Let me see
>>>>> how that goes. At this point, however, I am just short of options.
>>>>> Also raised this issue with the kvm mailing list but they are not too
>>>>> interested as it may not be high priority to them. I can't imagine
>>>>> that I am the only person hitting this issue and if this issue is
>>>>> purely EFI specific.
>>>>>
>>>>> Thanks,
>>>>> Adhyas
>>>>>
>>>>> On Sun, Nov 14, 2010 at 11:53 AM, Adhyas Avasthi <***@gmail.com> wrote:
>>>>>>

[Jordan Justen]

On Sun, Nov 14, 2010 at 23:23, Adhyas Avasthi <***@gmail.com> wrote:
> But I don't get the mouse to move within the VM. So I tried adding a
> USB mouse instead with -usb -usbdevice mouse, but now the VM is taking
> forever to respond. Were you able to get mouse? Anything specific you
> used on the command prompt?

I am not using USB right now:
qemu -m 512 -L . -cdrom cdrom.img -serial file:serial.log

I noticed that the mouse does not respond until I click in the window
once. After that, it seems to track fine moving in and out of the VM
window. The same seems to happen for me with a legacy boot.

-Jordan

[Jordan Justen]

On Sun, Nov 14, 2010 at 23:18, Adhyas Avasthi <***@gmail.com> wrote:
> The boot loader is awfully slow, however. It takes me about half a
> minute (approximately) before I select the boot method from the boot
> loader screen and I get the ExitBootServices call. The OS is
> relatively faster though.

I did notice that legacy boots fully to the Live CD desktop in 25
seconds vs. 70 seconds for OVMF. It would be nice to track that down,
but it is already greatly improved by being able to use kvm.

-Jordan

[Adhyas Avasthi]

Yes, I agree, this is live-able for now. I can look into the
performance aspect of it later on (perhaps the next thing on my list
is to install Ubuntu and then maybe worry about openSUSE which uses
elilo, and then worry about other aspects such as performance).

BTW, the mouse does work using installed qemu on Ubuntu, not with my
locally compiled one. I will work on that issue later on.

Thanks,
Adhyas

On Sun, Nov 14, 2010 at 11:33 PM, Jordan Justen <***@gmail.com> wrote:
> On Sun, Nov 14, 2010 at 23:18, Adhyas Avasthi <***@gmail.com> wrote:
>> The boot loader is awfully slow, however. It takes me about half a
>> minute (approximately) before I select the boot method from the boot
>> loader screen and I get the ExitBootServices call. The OS is
>> relatively faster though.
>
> I did notice that legacy boots fully to the Live CD desktop in 25
> seconds vs. 70 seconds for OVMF.  It would be nice to track that down,
> but it is already greatly improved by being able to use kvm.
>
> -Jordan
>
> ------------------------------------------------------------------------------
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> _______________________________________________
> edk2-devel mailing list
> edk2-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>



--
Adhyas
********************************************************************
Two types have compatible type if their types are the same.
    — ANSI C Standard, 3.1.2.6.
********************************************************************

[Adhyas Avasthi]

So, Ubuntu installed fine on the virtual hard disk as well. There were
a couple of issues. Shutdown/Reboot does not work, the VM just hangs.
The boot loader is not started automatically (perhaps this is because
the loader resides at /efi/ubuntu/grub.efi which is not hard coded
into EFI, and maybe they are not writing the appropriate NVRAM file.
Also, the NVRAM driver I am using in EFI may not be non-volatile. I
will look into this as I get time.

The total time is not too bad once we are out of the loader and into
the kernel. It is comparable to VM on legacy BIOS (obviously). I got
complete install done in less than 30 minutes.

Thanks,
Adhyas


On Sun, Nov 14, 2010 at 11:43 PM, Adhyas Avasthi <***@gmail.com> wrote:
> Yes, I agree, this is live-able for now. I can look into the
> performance aspect of it later on (perhaps the next thing on my list
> is to install Ubuntu and then maybe worry about openSUSE which uses
> elilo, and then worry about other aspects such as performance).
>
> BTW, the mouse does work using installed qemu on Ubuntu, not with my
> locally compiled one. I will work on that issue later on.
>
> Thanks,
> Adhyas
>
> On Sun, Nov 14, 2010 at 11:33 PM, Jordan Justen <***@gmail.com> wrote:
>> On Sun, Nov 14, 2010 at 23:18, Adhyas Avasthi <***@gmail.com> wrote:
>>> The boot loader is awfully slow, however. It takes me about half a
>>> minute (approximately) before I select the boot method from the boot
>>> loader screen and I get the ExitBootServices call. The OS is
>>> relatively faster though.
>>
>> I did notice that legacy boots fully to the Live CD desktop in 25
>> seconds vs. 70 seconds for OVMF.  It would be nice to track that down,
>> but it is already greatly improved by being able to use kvm.
>>
>> -Jordan
>>
>> ------------------------------------------------------------------------------
>> Centralized Desktop Delivery: Dell and VMware Reference Architecture
>> Simplifying enterprise desktop deployment and management using
>> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
>> client virtualization framework. Read more!
>> http://p.sf.net/sfu/dell-eql-dev2dev
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>>
>
>
>
> --
> Adhyas
> ********************************************************************
> Two types have compatible type if their types are the same.
>     — ANSI C Standard, 3.1.2.6.
> ********************************************************************
>



--
Adhyas
********************************************************************
Two types have compatible type if their types are the same.
    — ANSI C Standard, 3.1.2.6.
********************************************************************

[Andrew Fish]

I can't help with the Linux part, but I understand the calling convention issues really well as I ported the UnixPkg to support SEC being Unix calling convention while the rest of the code was EFI calling conventions. So feel free to ask questions if you need help figuring it out.

Here is example code that calls between the calling convention. Most of this code is EFI calling Unix, but the reverse stuff is Unix calling EFI:
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/UnixPkg/Sec/X64/MangleGasket.S

Andrew Fish





On Nov 13, 2010, at 3:20 PM, Adhyas Avasthi wrote:

> Alright, I think I have been able to root cause the issue in the case
> of Grub Boot Loader with kvm enabled. This is a case of calling
> convention issues between efi and gcc. While Grub has a call wrapper
> assembly file that seems to do the right thing for the calling
> convention required by efi, it does not work when kvm is enabled. The
> assembly file does the right thing with kvm disabled (pure qemu
> emulation).
>
> With kvm enabled, the instructions (I assume) get executed on the real
> host's cpu. I have no idea why that would mess up with the calling
> convention. Does anyone have a pointer on what I can put in as a quick
> hack to solve things. Here is the sample wrapper function from grub's
> source code that gets invoked before making the call to efi.
>
> /*
> * x86_64 uses registry to pass parameters. Unfortunately, gcc and efi use
> * different call conversion, so we need to do some conversion.
> *
> * gcc:
> * %rdi, %esi, %rdx, %rcx, %r8, %r9, 8(%rsp), 16(%rsp), ...
> *
> * efi:
> * %rcx, %rdx, %r8, %r9, 32(%rsp), 40(%rsp), 48(%rsp), ...
> *
> */
>
> FUNCTION(efi_wrap_4)
> subq $40, %rsp
> mov %r8, %r9
> mov %rcx, %r8
> mov %rsi, %rcx
> call *%rdi
> addq $40, %rsp
> ret
>
> Thanks,
> Adhyas
>
> On Fri, Nov 12, 2010 at 3:51 PM, Adhyas Avasthi <***@gmail.com> wrote:
>> Looking at kernel sources, I guess the kernel just reboots to where we
>> are jumping into it from the boot loader. Did someone really test the
>> openSUSE efi boot ever?
>>
>> From the kernel sources file arch/x86/boot/header.S (the beginning of
>> bzImage where the boot loader jumps):
>>
>> bootsect_start:
>> # Normalize the start address
>> ljmp $BOOTSEG, $start2
>>
>> start2:
>> movw %cs, %ax
>> movw %ax, %ds
>> movw %ax, %es
>> movw %ax, %ss
>> xorw %sp, %sp
>> sti
>> cld
>>
>> movw $bugger_off_msg, %si
>>
>> msg_loop:
>> lodsb
>> andb %al, %al
>> jz bs_die
>> movb $0xe, %ah
>> movw $7, %bx
>> int $0x10
>> jmp msg_loop
>>
>> bs_die:
>> # Allow the user to press a key, then reboot
>> xorw %ax, %ax
>> int $0x16
>> int $0x19
>>
>> # int 0x19 should never return. In case it does anyway,
>> # invoke the BIOS reset code...
>> ljmp $0xf000,$0xfff0
>>
>> I have matched it byte by byte, and this is what I seem to be
>> executing causing all the resets.
>> Anyone here familiar with the early kernel code and what should I call
>> within the kernel image for an EFI boot ?
>>
>> Thanks,
>> Adhyas
>>
>> On Fri, Nov 12, 2010 at 2:34 PM, Adhyas Avasthi <***@gmail.com> wrote:
>>> I could not get any kernel output by appending what you suggested.
>>>
>>> More find. I debugged elilo to find out that elilo loads the kernel
>>> just fine, and then it is the kernel that reboots my machine all the
>>> time. Something funny is going on with the kernel start.
>>> On further debugging, I found some more interesting stuff. Seems like
>>> for openSUSE, they keep the kernel bzImage and initrd on the same boot
>>> fat filesystem as the boot loader itself. A hex dump of the bzImage
>>> shows that the start of the image is a jump to 0x7C00 (on EFI ??). And
>>> elilo jumps to this instruction after loading the kernel. I think I
>>> went into no-man's land after that.
>>> Why would the kernel want to jump to 0x7C00 for an EFI Boot?
>>>
>>> elilo had some commented out code that put some bytes at 7C00. I
>>> uncommented the code in my build, but no progress. This code basically
>>> moved me back into real mode and then tried to jump to startup.S of
>>> the kernel itself. But still nothing really happened.
>>>
>>> I guess the VM reboot is happening because of random code execution
>>> leading me nowhere and is not intentional.
>>>
>>> I am trying to get hold of the elilo guys now to discuss these issues with them.
>>>
>>> - Adhyas
>>>
>>> On Thu, Nov 11, 2010 at 1:05 PM, Jordan Justen <***@gmail.com> wrote:
>>>> On Thu, Nov 11, 2010 at 11:37, Adhyas Avasthi <***@gmail.com> wrote:
>>>>> eLilo looks much better. It has both initrd and kernel images as part of the
>>>>> Boot FAT partition and loads them successfully. I also get the
>>>>> ExitBootServices call from the loader. Soon after that my VM reboots, so I
>>>>> cannot boot to the OS. Not sure where the issue resides though.
>>>>
>>>> Try adding console=ttyS0,115200n8 to the kernel command line.
>>>> (Actually, I think console=ttyS0 should work fine on its own for
>>>> qemu.)
>>>>
>>>> Then use '-serial file:serial.out' for qemu to capture the serial output.
>>>>
>>>> -Jordan
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Centralized Desktop Delivery: Dell and VMware Reference Architecture
>>>> Simplifying enterprise desktop deployment and management using
>>>> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
>>>> client virtualization framework. Read more!
>>>> http://p.sf.net/sfu/dell-eql-dev2dev
>>>> _______________________________________________
>>>> edk2-devel mailing list
>>>> edk2-***@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>>>>
>>>
>>>
>>>
>>> --
>>> Adhyas
>>> ********************************************************************
>>> Two types have compatible type if their types are the same.
>>> — ANSI C Standard, 3.1.2.6.
>>> ********************************************************************
>>>
>>
>>
>>
>> --
>> Adhyas
>> ********************************************************************
>> Two types have compatible type if their types are the same.
>> — ANSI C Standard, 3.1.2.6.
>> ********************************************************************
>>
>
>
>
> --
> Adhyas
> ********************************************************************
> Two types have compatible type if their types are the same.
> — ANSI C Standard, 3.1.2.6.
> ********************************************************************
>
> ------------------------------------------------------------------------------
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> _______________________________________________
> edk2-devel mailing list
> edk2-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

[Adhyas Avasthi]

Andrew

Thanks for the response. It seems something definitely is fishy. I
used the code from MangleGasket.S (reproduced below) as the
implementation of efi_call_4

//
// UNIX ABI to EFI ABI call
//
// UINTN
// ReverseGasketUint64 (
// void *Api,
// UINTN Arg1,
// UINTN Arg2,
// UINTN Arg3
// );
ASM_GLOBAL ASM_PFX(ReverseGasketUint64)
ASM_PFX(ReverseGasketUint64):
movq %rdi, %rax // Swizzle args
movq %rsi, %r9
// movq %rdx, %rdx
movq %rcx, %r8
movq %r9, %rcx

subq $40, %rsp // 32-byte shadow space plus alignment pad
call *%rax
addq $40, %rsp

ret


But the end result is same. I can execute this code without kvm but
with kvm enabled, the code gives an exception. This surprises me. It
seems that my host CPU (used with kvm enabled) is giving that
exception while the emulated CPU runs fine. I fail to understand. Not
sure if this helps, but the cat /proc/cpuinfo of my machine is also
attached with this email.

- Adhyas

On Sat, Nov 13, 2010 at 8:05 PM, Andrew Fish <***@apple.com> wrote:
> I can't help with the Linux part, but I understand the calling convention issues really well as I ported the UnixPkg to support SEC being Unix calling convention while the rest of the code was  EFI calling conventions. So feel free to ask questions if you need help figuring it out.
>
> Here is example code that calls between the calling convention. Most of this code is EFI calling Unix, but the reverse stuff is Unix calling EFI:
> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/UnixPkg/Sec/X64/MangleGasket.S
>
> Andrew Fish
>
>
>
>
>
> On Nov 13, 2010, at 3:20 PM, Adhyas Avasthi wrote:
>
>> Alright, I think I have been able to root cause the issue in the case
>> of Grub Boot Loader with kvm enabled. This is a case of calling
>> convention issues between efi and gcc. While Grub has a call wrapper
>> assembly file that seems to do the right thing for the calling
>> convention required by efi, it does not work when kvm is enabled. The
>> assembly file does the right thing with kvm disabled (pure qemu
>> emulation).
>>
>> With kvm enabled, the instructions (I assume) get executed on the real
>> host's cpu. I have no idea why that would mess up with the calling
>> convention. Does anyone have a pointer on what I can put in as a quick
>> hack to solve things. Here is the sample wrapper function from grub's
>> source code that gets invoked before making the call to efi.
>>
>> /*
>> * x86_64 uses registry to pass parameters. Unfortunately, gcc and efi use
>> * different call conversion, so we need to do some conversion.
>> *
>> * gcc:
>> *   %rdi,  %esi,  %rdx,  %rcx, %r8, %r9, 8(%rsp), 16(%rsp), ...
>> *
>> * efi:
>> *   %rcx,  %rdx,  %r8,  %r9,  32(%rsp), 40(%rsp), 48(%rsp), ...
>> *
>> */
>>
>> FUNCTION(efi_wrap_4)
>>        subq $40, %rsp
>>        mov %r8, %r9
>>        mov %rcx, %r8
>>        mov %rsi, %rcx
>>        call *%rdi
>>        addq $40, %rsp
>>        ret
>>
>> Thanks,
>> Adhyas
>>
>> On Fri, Nov 12, 2010 at 3:51 PM, Adhyas Avasthi <***@gmail.com> wrote:
>>> Looking at kernel sources, I guess the kernel just reboots to where we
>>> are jumping into it from the boot loader. Did someone really test the
>>> openSUSE efi boot ever?
>>>

[unknown]

--90e6ba6e85f485094e04938c6352
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Adhyas,

I was able to enable USB keyboard with the attached patch while using
qemu 0.12.3.
I added '-usb -usbdevice keyboard' to the qemu command line.

You can also comment UsbKbDxe.inf line in the .fdf to verify that ovmf
will not have any console input after booting.

-Jordan

On Tue, Oct 26, 2010 at 11:33, Adhyas Avasthi <***@gmail.com> wrote:
> Interestingly, the Supported routine is never invoked either. I just checked
> that if the Supported routine was really invoked for this device, it would
> have returned SUCCESS, but it never was invoked.
> The Serial dump tells me that the PCI Bus did find the device at devfn 0x20
> on scan. How come it never called the USB handler? Do I need to add any
> other driver as well?
>
> Thanks,
> Adhyas
>
> On Mon, Oct 25, 2010 at 7:23 PM, Tian, Feng <***@intel.com> wrote:
>>
>> As you say UHCI driver doesn’t run, so it should be
>> DriverBindingSupported() return error.
>>
>> DriverBindingSupported() just read pci config header and judge the class
>> code to see if it’s ehci or uhci.
>>
>>

[unknown]

Adhyas,

I have successfully loaded Ubuntu 10.10 x86-64 which now supports UEFI.

I have also loaded Fedora 12's special UEFI boot.iso from:
http://download.fedoraproject.org/pub/fedora/linux/releases/12/Fedora/x86_6=
4/os/images/

But, the same image from Fedora 13 failed to boot on OVMF.

You should also try adding the '-no-kvm' option to qemu. I think kvm
should work in some cases, but if you are having trouble, give it a
shot.

-Jordan

On Tue, Oct 26, 2010 at 16:34, Adhyas Avasthi <***@gmail.com> wrote:
> Moving forward on this effort, I am now trying to boot SUSE Linux x64 11.=
3
> version which supports EFI. I am using a default QEMU VM for that, so no
> customizations there. Has anyone tried that with success?
>
> I can see the boot loader and it loads kernel and initrd but resets the V=
M
> soon after it loads the files and tries to execute them.
> I will spend some more cycles to debug this further but if there are
> pointers I will appreciate them.
>
> Thanks,
> Adhyas
>
> On Tue, Oct 26, 2010 at 3:20 PM, Adhyas Avasthi <***@gmail.com> wrote:
>>
>> Yes, I did not realize that I also needed to modify the fdf file to
>> include the Usb drivers there as well. I modified the dsc file (as I use=
d to
>> do in EDK 1) and that did not work. Thanks for all the responses. It doe=
s
>> work for me now and I can have USB input.
>>
>> Thanks,
>> Adhyas
>>
>>
>> On Tue, Oct 26, 2010 at 3:11 PM, Jordan Justen <***@gmail.com> wrot=
e:
>>>
>>> Adhyas,
>>>
>>> I was able to enable USB keyboard with the attached patch while using
>>> qemu 0.12.3.
>>> I added '-usb -usbdevice keyboard' to the qemu command line.
>>>
>>> You can also comment UsbKbDxe.inf line in the .fdf to verify that ovmf
>>> will not have any console input after booting.
>>>
>>> -Jordan
>>>
>>> On Tue, Oct 26, 2010 at 11:33, Adhyas Avasthi <***@gmail.com> wrote:
>>> > Interestingly, the Supported routine is never invoked either. I just
>>> > checked
>>> > that if the Supported routine was really invoked for this device, it
>>> > would
>>> > have returned SUCCESS, but it never was invoked.
>>> > The Serial dump tells me that the PCI Bus did find the device at devf=
n
>>> > 0x20
>>> > on scan. How come it never called the USB handler? Do I need to add a=
ny
>>> > other driver as well?
>>> >
>>> > Thanks,
>>> > Adhyas
>>> >
>>> > On Mon, Oct 25, 2010 at 7:23 PM, Tian, Feng <***@intel.com>
>>> > wrote:
>>> >>
>>> >> As you say UHCI driver doesn=92t run, so it should be
>>> >> DriverBindingSupported() return error.
>>> >>
>>> >> DriverBindingSupported() just read pci config header and judge the
>>> >> class
>>> >> code to see if it=92s ehci or uhci.
>>> >>
>>> >>

[unknown]

Adhyas,

I got the same results as you. (at least 5 minutes for a boot)

I also noted that the slow boot speed on Ubuntu 10.10 is reproducible
with -no-kvm and a legacy boot of qemu. I am pretty surprised that
kvm would make that much of a difference (20 seconds vs. maybe 10
minutes), so I suspect something else might be going wrong.

I have not had a chance to investigate the crash with OVMF when kvm is
enabled, but OVMF can boot to the shell at least with kvm enabled.

-Jordan

On Wed, Nov 10, 2010 at 19:26, Adhyas Avasthi <***@gmail.com> wrote:
> Some more debug find. It seems that the Grub2 bootloader in Ubuntu 10.10
> crashes the system soon after it is started with -enable-kvm option.
> Here is the output from serial log:
>
> !!!! X64 Exception Type - 000000000000000D !!!!
> ExceptionData - 0000000000000000
> RIP - 000000001FFA937A, RFL - 0000000000010206
> RAX - 000000001FF351C0, RCX - 0000000000000000, RDX - 000000001FFBB1B0
> RBX - 000000001FF35400, RSP - 000000001FF97540, RBP - 000000001FFBB1B0
> RSI - 000000001FFBB1F0, RDI - 000000001FF35200
> R8=A0 - 0000000000000000, R9=A0 - 000000001FFBB1EF, R10 - 000000001E5E172=
8
> R11 - 000000001FF973D8, R12 - 000000001FFB6810, R13 - 0000000000000070
> R14 - 000000001DDBAFFF, R15 - 0000000000000060
> CS=A0 - 0028, DS=A0 - 0008, ES=A0 - 0008, FS=A0 - 0008, GS=A0 - 0008, SS=
=A0 - 0008
> GDT - 000000001FF1CE98; 003F,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 IDT - 000000001FE88BC0; 0FFF
> LDT - 0000000000000000, TR=A0 - 0000000000000000
> CR0 - 0000000080000023, CR2 - 0000000000000000, CR3 - 000000001FF36000
> CR4 - 0000000000000668, CR8 - 0000000000000000
> DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
> DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
>
> Trying to get Grub2 sources to identify the root cause. Any pointers are
> welcome.
>
> Thanks,
> Adhyas
>
>
> On Wed, Nov 10, 2010 at 6:27 PM, Adhyas Avasthi <***@gmail.com> wrote:
>>
>> Alright, if I wait long enough (long means about 15 minutes), I can see
>> the graphics display from Ubuntu. Still a blank colored graphics screen =
with
>> nothing on it. I guess this is because I am running with the no-kvm opti=
on.
>> Perhaps the rest of Ubuntu will also come up if I give it enough time (l=
ike,
>> maybe over night) :-)
>>
>> But such speed is just not acceptable for me to be able to use OVMF for
>> any VM booting work. Does anyone know why does OVMF not boot to even gru=
b
>> with kvm enabled? If I enable kvm, I could not even see the grub screen =
in
>> the VM. I would like to fix it, so if you have any pointers, please let =
me
>> know and I can try to take a look into the code.
>>
>> Thanks,
>> Adhyas
>>
>> On Wed, Nov 10, 2010 at 5:58 PM, Adhyas Avasthi <***@gmail.com> wrote=
:
>>>
>>> Jordan
>>>
>>> Can you share specific details of your experiment? I am trying to make =
it
>>> run now and am not successful using out of the box code components, so =
I am
>>> working towards fixing the issue, if it exists.
>>>
>>> To clarify, can you share the qemu command you can use to start a VM wi=
th
>>> Ubuntu10.10 x86-64 ISO attached that can boot into the VM ? Did you hav=
e any
>>> other specific changes in BIOS or qemu ?
>>>
>>> I will appreciate any pointers in this regard.
>>>
>>>