From: "Richard W.M. Jones" <rjones@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Alex <alex3kov@zoho.com>,
Xiao Guangrong <guangrong.xiao@linux.intel.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Shannon Zhao <zhaoshenglong@huawei.com>,
Michael Tokarev <mjt@tls.msk.ru>,
qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
Igor Mammedov <imammedo@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/4] set the OEM fields in the RSDT and the FADT from the SLIC
Date: Thu, 21 Jan 2016 11:37:46 +0000 [thread overview]
Message-ID: <20160121113746.GO1766@redhat.com> (raw)
In-Reply-To: <5697CE49.9090005@redhat.com>
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
next prev parent reply other threads:[~2016-01-21 11:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-14 1:36 [Qemu-devel] [PATCH 0/4] set the OEM fields in the RSDT and the FADT from the SLIC Laszlo Ersek
2016-01-14 1:36 ` [Qemu-devel] [PATCH 1/4] acpi: take oem_id in build_header(), optionally Laszlo Ersek
2016-01-14 1:36 ` [Qemu-devel] [PATCH 2/4] acpi: expose oem_id and oem_table_id in build_rsdt() Laszlo Ersek
2016-01-14 1:36 ` [Qemu-devel] [PATCH 3/4] acpi: stash the OEM ID and OEM Table ID fields from an external SLIC table Laszlo Ersek
2016-01-14 10:21 ` Michael S. Tsirkin
2016-01-14 16:38 ` Laszlo Ersek
2016-01-14 1:36 ` [Qemu-devel] [PATCH 4/4] pc: set the OEM fields in the RSDT and the FADT from the SLIC Laszlo Ersek
2016-01-14 10:24 ` Michael S. Tsirkin
2016-01-14 16:44 ` Laszlo Ersek
2016-01-14 17:09 ` Laszlo Ersek
2016-01-14 10:03 ` [Qemu-devel] [PATCH 0/4] " Richard W.M. Jones
2016-01-14 10:06 ` Alex
2016-01-14 10:23 ` Richard W.M. Jones
2016-01-14 16:35 ` Laszlo Ersek
2016-01-15 16:07 ` Richard W.M. Jones
2016-01-15 16:13 ` Alex
2016-01-21 11:37 ` Richard W.M. Jones [this message]
2016-01-21 11:42 ` Michael Tokarev
2016-01-21 11:44 ` Richard W.M. Jones
2016-01-21 11:55 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160121113746.GO1766@redhat.com \
--to=rjones@redhat.com \
--cc=alex3kov@zoho.com \
--cc=guangrong.xiao@linux.intel.com \
--cc=imammedo@redhat.com \
--cc=lersek@redhat.com \
--cc=mjt@tls.msk.ru \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=zhaoshenglong@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.