Re: [Qemu-devel] [PATCH 0/4] set the OEM fields in the RSDT and the FADT from the SLIC
On 01/21/16 12:42, Michael Tokarev wrote: > 21.01.2016 14:37, Richard W.M. Jones wrote: > >> I'm afraid I gave up on this -- did give it my best. It turns out >> that the machine that I thought supported UEFI boot does not. I'll >> keep an eye out for such a machine and test this in future. > > BTW, why do you guys refer to UEFI boot all the time? The whole thing > is equally useful on traditional BIOS-booting machines too. Windows7 > uses the same mechanism (looking at RSDT) for offline activation no > matter if it is EFI system or not. > > When I did first version of my patch (based on someone else's version, > but details escapes my memory already), there was no UEFI support for > qemu whatsoever, and it allowed me to use my OEM version of Windows7 > inside a qemu virtual machine without second activation. I've been referring to UEFI because my interest was renewed in this topic by the following OVMF problem report: https://github.com/tianocore/edk2/issues/5 Of course, the issue is not specific to OVMF (that's why I posted the patches for QEMU), but I guess it stuck in my mind. Sorry. Laszlo
Re: [Qemu-devel] [PATCH 0/4] set the OEM fields in the RSDT and the FADT from the SLIC
On Thu, Jan 14, 2016 at 05:35:21PM +0100, Laszlo Ersek wrote: > On 01/14/16 11:23, Richard W.M. Jones wrote: > > On Thu, Jan 14, 2016 at 01:06:05PM +0300, Alex wrote: > >> Richard, I just posted HW test results to > >> https://bugzilla.redhat.com/show_bug.cgi?id=1248758. > >> Should I do it here instead? > > > > I saw that. Testing a virt-p2v conversion is a lot more involved. It > > would involve something like this: > > > > (1) Install Win7 on a UEFI-based physical machine, ensuring that Win7 > > is using UEFI to boot (not CSM or BIOS). > > > > (2) Install a recent Fedora on a second machine (second machine may be > > a VM). 'dnf install virt-v2v' on this machine. > > > > (3) Boot virt-p2v ISO (http://oirase.annexia.org/virt-p2v/) on the > > first physical machine. Perform a P2V conversion > > (http://libguestfs.org/virt-p2v.1.html). > > > > (4) Boot the converted Win7 VM on the target qemu. Reproduce the > > original bug. We have never had the original bug reported to us by > > any customer. > > > > (5) Patch qemu on the target. > > > > (6) Boot virt-p2v ISO again, and perform a second conversion. > > > > (7) Verify that the bug (step 4) has been fixed. > > Very good description, thank you. > > > While I was looking at Laszlo's patches just now, I realized that I > > have an AMD box that uses UEFI (actually - it uses CSM right now, but > > I think I can make it boot using pure UEFI). I'll have to swap some > > disks around but I may be able to try this out today or tomorrow if I > > can find a spare hard disk. > > That would be awesome, yes. Thanks! I'm afraid I gave up on this -- did give it my best. It turns out that the machine that I thought supported UEFI boot does not. I'll keep an eye out for such a machine and test this in future. All was not lost because I did discover a few bugs in virt-p2v along the way: https://github.com/libguestfs/libguestfs/commit/7e2f2b0b2410587b81fd42bf741e3a36a5e75f6f https://github.com/libguestfs/libguestfs/commit/c3ebc0a83761c552e6c19163b6d87044ae1ca635 https://github.com/libguestfs/libguestfs/commit/3f376fa5137d73df681cc5eaaa9b5e4206d57fce https://github.com/libguestfs/libguestfs/commit/d723b352f8c10fb5244f17889cf68e13dd85c037 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top
Re: [Qemu-devel] [PATCH 0/4] set the OEM fields in the RSDT and the FADT from the SLIC
On Thu, Jan 21, 2016 at 02:42:02PM +0300, Michael Tokarev wrote: > 21.01.2016 14:37, Richard W.M. Jones wrote: > > > I'm afraid I gave up on this -- did give it my best. It turns out > > that the machine that I thought supported UEFI boot does not. I'll > > keep an eye out for such a machine and test this in future. > > BTW, why do you guys refer to UEFI boot all the time? The whole thing > is equally useful on traditional BIOS-booting machines too. Windows7 > uses the same mechanism (looking at RSDT) for offline activation no > matter if it is EFI system or not. > > When I did first version of my patch (based on someone else's version, > but details escapes my memory already), there was no UEFI support for > qemu whatsoever, and it allowed me to use my OEM version of Windows7 > inside a qemu virtual machine without second activation. Could really do with detailed steps to reproduce the problem. We have never observed it, and I know next to nothing about how "activation" works. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/
Re: [Qemu-devel] [PATCH 0/4] set the OEM fields in the RSDT and the FADT from the SLIC
21.01.2016 14:37, Richard W.M. Jones wrote: > I'm afraid I gave up on this -- did give it my best. It turns out > that the machine that I thought supported UEFI boot does not. I'll > keep an eye out for such a machine and test this in future. BTW, why do you guys refer to UEFI boot all the time? The whole thing is equally useful on traditional BIOS-booting machines too. Windows7 uses the same mechanism (looking at RSDT) for offline activation no matter if it is EFI system or not. When I did first version of my patch (based on someone else's version, but details escapes my memory already), there was no UEFI support for qemu whatsoever, and it allowed me to use my OEM version of Windows7 inside a qemu virtual machine without second activation. Thanks, /mjt
Re: [Qemu-devel] [PATCH 0/4] set the OEM fields in the RSDT and the FADT from the SLIC
On 15/01/16 19:07, Richard W.M. Jones wrote: On Thu, Jan 14, 2016 at 05:35:21PM +0100, Laszlo Ersek wrote: On 01/14/16 11:23, Richard W.M. Jones wrote: On Thu, Jan 14, 2016 at 01:06:05PM +0300, Alex wrote: Richard, I just posted HW test results to https://bugzilla.redhat.com/show_bug.cgi?id=1248758. Should I do it here instead? I saw that. Testing a virt-p2v conversion is a lot more involved. It would involve something like this: (1) Install Win7 on a UEFI-based physical machine, ensuring that Win7 is using UEFI to boot (not CSM or BIOS). (2) Install a recent Fedora on a second machine (second machine may be a VM). 'dnf install virt-v2v' on this machine. (3) Boot virt-p2v ISO (http://oirase.annexia.org/virt-p2v/) on the first physical machine. Perform a P2V conversion (http://libguestfs.org/virt-p2v.1.html). (4) Boot the converted Win7 VM on the target qemu. Reproduce the original bug. We have never had the original bug reported to us by any customer. (5) Patch qemu on the target. (6) Boot virt-p2v ISO again, and perform a second conversion. (7) Verify that the bug (step 4) has been fixed. Very good description, thank you. I made a good faith attempt to test this, but my attempts to get Windows installed failed at the first step. I don't have an optical drive (who does?) and the MSFT tool that I tried for converting the MSDN-supplied Win7 ISO into a USB key resulted only in USB keys that did not boot at all. It'll need to wait until I find an optical drive. Rich. Had this problem as well - this program http://rufus.akeo.ie/ can create UEFI-bootable USB stick from Win7 ISO. -- /--Regards, Alex/
Re: [Qemu-devel] [PATCH 0/4] set the OEM fields in the RSDT and the FADT from the SLIC
On Thu, Jan 14, 2016 at 05:35:21PM +0100, Laszlo Ersek wrote: > On 01/14/16 11:23, Richard W.M. Jones wrote: > > On Thu, Jan 14, 2016 at 01:06:05PM +0300, Alex wrote: > >> Richard, I just posted HW test results to > >> https://bugzilla.redhat.com/show_bug.cgi?id=1248758. > >> Should I do it here instead? > > > > I saw that. Testing a virt-p2v conversion is a lot more involved. It > > would involve something like this: > > > > (1) Install Win7 on a UEFI-based physical machine, ensuring that Win7 > > is using UEFI to boot (not CSM or BIOS). > > > > (2) Install a recent Fedora on a second machine (second machine may be > > a VM). 'dnf install virt-v2v' on this machine. > > > > (3) Boot virt-p2v ISO (http://oirase.annexia.org/virt-p2v/) on the > > first physical machine. Perform a P2V conversion > > (http://libguestfs.org/virt-p2v.1.html). > > > > (4) Boot the converted Win7 VM on the target qemu. Reproduce the > > original bug. We have never had the original bug reported to us by > > any customer. > > > > (5) Patch qemu on the target. > > > > (6) Boot virt-p2v ISO again, and perform a second conversion. > > > > (7) Verify that the bug (step 4) has been fixed. > > Very good description, thank you. I made a good faith attempt to test this, but my attempts to get Windows installed failed at the first step. I don't have an optical drive (who does?) and the MSFT tool that I tried for converting the MSDN-supplied Win7 ISO into a USB key resulted only in USB keys that did not boot at all. It'll need to wait until I find an optical drive. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/
Re: [Qemu-devel] [PATCH 0/4] set the OEM fields in the RSDT and the FADT from the SLIC
On Thu, Jan 14, 2016 at 01:06:05PM +0300, Alex wrote: > Richard, I just posted HW test results to > https://bugzilla.redhat.com/show_bug.cgi?id=1248758. > Should I do it here instead? I saw that. Testing a virt-p2v conversion is a lot more involved. It would involve something like this: (1) Install Win7 on a UEFI-based physical machine, ensuring that Win7 is using UEFI to boot (not CSM or BIOS). (2) Install a recent Fedora on a second machine (second machine may be a VM). 'dnf install virt-v2v' on this machine. (3) Boot virt-p2v ISO (http://oirase.annexia.org/virt-p2v/) on the first physical machine. Perform a P2V conversion (http://libguestfs.org/virt-p2v.1.html). (4) Boot the converted Win7 VM on the target qemu. Reproduce the original bug. We have never had the original bug reported to us by any customer. (5) Patch qemu on the target. (6) Boot virt-p2v ISO again, and perform a second conversion. (7) Verify that the bug (step 4) has been fixed. While I was looking at Laszlo's patches just now, I realized that I have an AMD box that uses UEFI (actually - it uses CSM right now, but I think I can make it boot using pure UEFI). I'll have to swap some disks around but I may be able to try this out today or tomorrow if I can find a spare hard disk. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/
Re: [Qemu-devel] [PATCH 0/4] set the OEM fields in the RSDT and the FADT from the SLIC
Richard, I just posted HW test results to https://bugzilla.redhat.com/show_bug.cgi?id=1248758. Should I do it here instead? I'm not a RHEL customer, but I am semi-responsible for raising this fuss :) *From:* Richard W.m. Jones *Sent:* Thursday, January 14, 2016 1:03PM *To:* Laszlo Ersek *Cc:* Qemu-devel, Michael S. Tsirkin, Aleksei Kovura, Igor Mammedov, Michael Tokarev, Paolo Bonzini, Shannon Zhao, Xiao Guangrong *Subject:* Re: [PATCH 0/4] set the OEM fields in the RSDT and the FADT from the SLIC On Thu, Jan 14, 2016 at 02:36:53AM +0100, Laszlo Ersek wrote: This matters mostly for Win7 installations that were converted with p2v. Testing feedback from such environments would be appreciated. Just to note first that no RHEL customer has ever reported this bug to us. To test this is going to require a spare UEFI-capable physical machine where I can install Windows 7, and I don't have such a machine. I could test it using a virt-p2v conversion from a VM, but then I guess we'd have to apply these patches to qemu before conversion, and so it wouldn't be clear to me exactly what we were testing. Anyway I'll keep an eye on this and if I get hardware capable of testing it, then I'll do so. Rich. /--Regards, Alex/
Re: [Qemu-devel] [PATCH 0/4] set the OEM fields in the RSDT and the FADT from the SLIC
On Thu, Jan 14, 2016 at 02:36:53AM +0100, Laszlo Ersek wrote: > This matters mostly for Win7 installations that were converted with p2v. > Testing feedback from such environments would be appreciated. Just to note first that no RHEL customer has ever reported this bug to us. To test this is going to require a spare UEFI-capable physical machine where I can install Windows 7, and I don't have such a machine. I could test it using a virt-p2v conversion from a VM, but then I guess we'd have to apply these patches to qemu before conversion, and so it wouldn't be clear to me exactly what we were testing. Anyway I'll keep an eye on this and if I get hardware capable of testing it, then I'll do so. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
Re: [Qemu-devel] [PATCH 0/4] set the OEM fields in the RSDT and the FADT from the SLIC
On 01/14/16 11:23, Richard W.M. Jones wrote: > On Thu, Jan 14, 2016 at 01:06:05PM +0300, Alex wrote: >> Richard, I just posted HW test results to >> https://bugzilla.redhat.com/show_bug.cgi?id=1248758. >> Should I do it here instead? > > I saw that. Testing a virt-p2v conversion is a lot more involved. It > would involve something like this: > > (1) Install Win7 on a UEFI-based physical machine, ensuring that Win7 > is using UEFI to boot (not CSM or BIOS). > > (2) Install a recent Fedora on a second machine (second machine may be > a VM). 'dnf install virt-v2v' on this machine. > > (3) Boot virt-p2v ISO (http://oirase.annexia.org/virt-p2v/) on the > first physical machine. Perform a P2V conversion > (http://libguestfs.org/virt-p2v.1.html). > > (4) Boot the converted Win7 VM on the target qemu. Reproduce the > original bug. We have never had the original bug reported to us by > any customer. > > (5) Patch qemu on the target. > > (6) Boot virt-p2v ISO again, and perform a second conversion. > > (7) Verify that the bug (step 4) has been fixed. Very good description, thank you. > While I was looking at Laszlo's patches just now, I realized that I > have an AMD box that uses UEFI (actually - it uses CSM right now, but > I think I can make it boot using pure UEFI). I'll have to swap some > disks around but I may be able to try this out today or tomorrow if I > can find a spare hard disk. That would be awesome, yes. Thanks! Cheers Laszlo
