[vfio-users] Physical disk passthrough and OVMF

[Blank Field]

Updated to fc24, got unbootable 4.5.0-rc7 kernel, qemu 2.5.0 and
edk2.git-0-20160324.b1635.gf0bbcdf.x86_64.
The problem still persists. I was able to jump into ovmf setup menu, the
drive is recognised. Trying booting from any partition results in a hang
and errors.
First it says about invalid MBR on a GPT disk, the last two lines of the
debug console are:
ExtractConfig: BlockToConfig(): Invalid Parameter, Progress="<null string>
ASSERT
/home/jenkins/workspace/edk2/rpmbuild/rpm/BUILD/edk2.git/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c(1256):
TmpRequest != ((void *) 0)

In short, updating to qemu 2.5 did not help.
On Mar 27, 2016 2:01 AM, "Blank Field" <ihatethisfield at gmail.com> wrote:

> OVMF is from git, upgrading QEMU ATM to 2.5.x. Apparently, fedora has 2.5
> qemu only in beta 24.
>
> Thanks for the advice, didn't know about the new qemu release.
> On Mar 27, 2016 1:01 AM, "Dan Ziemba" <zman0900 at gmail.com> wrote:
>
>> On Fri, 2016-03-25 at 01:10 +0300, Blank Field wrote:
>> > Hello again, fellow subscribers.
>> >
>> > Since 4.3.X kernels I am experiencing some strange problems with disk
>> > IO.
>> >
>> > I am passing through the whole /dev/sda(since i also dualboot into
>> > that system for some weird software or hardware) to my VM, and since
>> > recent versions of kernel the VM gets stuck in an endless loop,
>> > consuming 100% one core.
>> >
>> > The ISA debug console says stuff like:
>> > PartitionValidMbr: Bad MBR partition size EndingLBA(D99299D3) >
>> > LastLBA(31FFF)
>> >
>> > The thing is that the disk in question has nothing to do with MBR, it
>> > is formatted into GPT.
>> > I can't pinpoint the source of that weird D99299D3 number.
>> >
>> > That kind of error happens for every partition detected.
>> >
>> > Device          Start        End    Sectors   Size Type
>> > /dev/sda1        2048 1171875000 1171872953 558.8G Microsoft basic
>> > data
>> > /dev/sda2  1171875840 1172080639     204800   100M EFI System
>> > /dev/sda3  1172080640 1172342783     262144   128M Microsoft reserved
>> > /dev/sda4  1172342784 1465145343  292802560 139.6G Microsoft basic
>> > data
>> > /dev/sda5  1465145344 1953525134  488379791 232.9G Microsoft basic
>> > data
>> > That looks like a valid partition table for me. Moreover, the fact
>> > that i am able to boot an UEFI-capable system bare-metal confirms
>> > that
>> > the partition table is correct.
>> >
>> > I remember i've seen some related messages on the list in february or
>> > something, but they only stated the existence of this error.
>> >
>> > Have any of you seen stuff like that? If so, how do you live with it?
>> >
>> > Maybe i should write to edk2-devel mailing list for this, because it
>> > isn't much related to VFIO, but normal qemu folks rarely sacrifice
>> > the
>> > whole disk to a VM.
>> >
>> > Versions:
>> > QEMU emulator version 2.4.1 (qemu-2.4.1-7.fc23)
>> > kernel 4.4.5-300.fc23.x86_64(doesn't matter much from 4.3.X)
>> > edk2.git-0-20160311.b1594.gf6326d1.x86_64
>> >
>>
>> A lot of people had problems booting with OVMF with kernels 4.2 and
>> 4.3.  It's fixed for myself and I think most others with 4.4, but I
>> think you may need fairly recent qemu and ovmf versions.  Looks like
>> your OVMF is new enough if that date means what I think it does, but
>> you should try upgrading to qemu 2.5.
>>
>> _______________________________________________
>> vfio-users mailing list
>> vfio-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/vfio-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160328/e7cbed24/attachment.htm>