[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [vfio-users] Physical disk passthrough and OVMF



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 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 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 redhat com
https://www.redhat.com/mailman/listinfo/vfio-users

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]