On Wed, Mar 03, 2021 at 05:57:45PM -0800, Nick S wrote: > When you say "instal", do you mean configuring another VM with the same SSD in > libvirt? I am not actually using the manually compiled version of qemu with > libvirt, I just grabbed the command line from it and adjusted it a bit to work > separately. And the libvirt that created it is fairly recent. I can certainly > change the machine type there if you tell me what you want tested.
Sure, just change it to 5.2. > This is my > Windows to go image that I use in all kinds of places and it should be able to > boot in both UEFI and Bios modes. > > On Wed, Mar 3, 2021 at 2:06 PM Michael S. Tsirkin <m...@redhat.com> wrote: > > OK great, good to know. note it works because you > specified an old machine type as libvirt does for > old installed VMs. > > My next question then is, what happens if you install > a new VM? Does it work fine for you then? > > > On Wed, Mar 03, 2021 at 08:56:32AM -0800, Nick S wrote: > > This change works perfectly, thank you! > > > > On Wed, Mar 3, 2021 at 1:26 AM Michael S. Tsirkin <m...@redhat.com> > wrote: > > > > Can you try this please: > > > > git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/ > for_upstream > > > > ? > > > > > > On Tue, Mar 02, 2021 at 09:59:47PM -0800, Nick S wrote: > > > I found the commit that breaks my VM. Anybody has any background > on > why > > it was > > > done? The comments are fairly extensive, but they are Mac related > and I > > am > > > running Windows 10 with UEFI. My VM is pc-q35-4.2 and this change > > definitely > > > breaks Windows 10. Anything before I can check out, compile and it > runs > > fine. > > > Anything after this commit and it produces that boot device > inaccessible > > error. > > > Reverting this change on the current master also makes it work > fine. > > > > > > git diff af1b80ae56c9495999e8ccf7b70ef894378de642~ > > > af1b80ae56c9495999e8ccf7b70ef894378de642 > > > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c > > > index b7bcbbbb2a..7a5a8b3521 100644 > > > --- a/hw/i386/acpi-build.c > > > +++ b/hw/i386/acpi-build.c > > > @@ -1497,7 +1497,7 @@ build_dsdt(GArray *table_data, BIOSLinker > *linker, > > > dev = aml_device("PCI0"); > > > aml_append(dev, aml_name_decl("_HID", aml_eisaid > ("PNP0A03"))); > > > aml_append(dev, aml_name_decl("_ADR", aml_int(0))); > > > - aml_append(dev, aml_name_decl("_UID", aml_int(1))); > > > + aml_append(dev, aml_name_decl("_UID", aml_int(0))); > > > aml_append(sb_scope, dev); > > > aml_append(dsdt, sb_scope); > > > > > > @@ -1512,7 +1512,7 @@ build_dsdt(GArray *table_data, BIOSLinker > *linker, > > > aml_append(dev, aml_name_decl("_HID", aml_eisaid > ("PNP0A08"))); > > > aml_append(dev, aml_name_decl("_CID", aml_eisaid > ("PNP0A03"))); > > > aml_append(dev, aml_name_decl("_ADR", aml_int(0))); > > > - aml_append(dev, aml_name_decl("_UID", aml_int(1))); > > > + aml_append(dev, aml_name_decl("_UID", aml_int(0))); > > > aml_append(dev, build_q35_osc_method()); > > > aml_append(sb_scope, dev); > > > aml_append(dsdt, sb_scope); > > > > > > It looks like a regression issue in 5.2.x so I registered a bug > for > > it: https:/ > > > /bugs.launchpad.net/qemu/+bug/1917565 > > > > > > > > > On Sun, Feb 28, 2021 at 9:13 PM Nick S <nick.kv...@gmail.com> > wrote: > > > > > > > > > I have a VM set up on a USB SSD drive that I assign directly > using > > linux > > > device (-blockdev '{"driver":"host_device","filename":"/dev/ > disk/ > > by-id/ > > > > > > > scsi-1SanDisk_Extreme_SSD_20072F404043","aio":"native","node-name":"libvirt-2-storage","cache": > > > > > > > {"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}') > > > > > > I've been using it for a few years now and recently decided to > > compile the > > > most recent version of qemu to do some hacking. To my > surprise, > when > > I > > > compiled the master branch, Windows failed to load with the > "Boot > > Device > > > Inaccessible" error. I went through tags in git and the latest > tag > > that > > > works is 5.1.0. On 5.2.0-rc0 I started getting this error. Was > > something > > > changed recently for passing a linux block device as "raw"? > > > > > > Thank you, > > > Nick > > > > > > > > >