On 10/5/21 01:40, Ed Greshko wrote: <cpu mode="custom" match="exact" check="none"> <model fallback="forbid">Nehalem</model> </cpu> My VM worked properly on the W11 pre-release. The general release come out today: https://www.microsoft.com/en-us/software-download/windows11 And Nahalem is not supported. W11 general release wants a Comet Lake Coffee Lake

On 10/5/21 02:14, Ed Greshko wrote: We need a qemu-kvm CPU processor that supports Windows 11 https://bugzilla.redhat.com/show_bug.cgi?id=2010618 I have been trying it!

On 10/5/21 02:29, Ed Greshko wrote: What did you think "Okay, I give up..." meant?

On Tue, 2021-10-05 at 02:32 -0700, ToddAndMargo via users wrote: I read that as "I've been looking for this information and haven't found it". [Also, I wish people would stop quoting the entire text of a nested thread just to add a one-line comment.] poc

On Tue, 2021-10-05 at 19:55 +0800, Ed Greshko wrote: Yep. Always irritating. poc

On 05/10/2021 09:13, ToddAndMargo via users wrote: Does your 'actual' bare-metal CPU(s) is such that w11 will be happy with? I do not think 'qemu' can "fake" any CPU for you at your or anybody's whim, especially not 'KVM' You would normally think of 'qemu-kmv', when it comes to 'faking' a CPU(family) as "going down a shelf" Most revealing should be going with:   <cpu mode='host-passthrough' migratable='on(or off)'>     <cache mode='passthrough'/>   </cpu> And if your w11(btw. why would you bother with windows anyway - ahh... don't answer) is happy with that, then that's what you should be looking at in terms of closest sibling.

On Tue, 2021-10-05 at 12:16 -0700, ToddAndMargo via users wrote: Yet, my experience of Office gives me exactly the opposite response. -- uname -rsvp Linux 3.10.0-1160.42.2.el7.x86_64 #1 SMP Tue Sep 7 14:49:57 UTC 2021 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.

Tim: ToddAndMargo: No, but I understand the sentiment. Many years ago I had to help someone use Office. They'd gone on a course for it, and also had to do homework. Their home version was different from the school's version, and they couldn't transfer the knowledge. I had to delve through all the badly organised menus trying to find the functions they needed, then work out how they were going to apply to the data on the page. Nothing was intuitive. It's all about learning its foibles. It doesn't help when the knowledge is only presented as recipes. Rather than a task of "format the page in landscape, title the page and add a table with the items and prices listed below in a coherent manner" they're given a list of "from the so-and-so menu pick this, then put 8 and 3 into the first two boxes" etc. The moment MS rearranges the menus, which they continually do, they're lost. Few complicated applications are straight-forward, but I've always found Office to be far worse. Fortunately, I don't use most of the fancy functions, and likewise for most people. It's a glorified typewriter with editing and storage. Though, in the past, I have used some of the more useful automation features, like generating tables of contents and indexes. And I have played with merging and splitting table cells. Over the last several years, I mostly use it to type up chord charts for guitarists who can't read musical scores. That's little more than heading, sub-heading, body text, and then adjust the styling to fill the page as best possible, with a few text boxes for playing hints. -- uname -rsvp Linux 3.10.0-1160.42.2.el7.x86_64 #1 SMP Tue Sep 7 14:49:57 UTC 2021 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.

On Tue, 5 Oct 2021 at 17:28, Tim via users <users(a)lists.fedoraproject.org&gt; wrote: Office suits the use case of a large organization with a "corporate standard" configuration. I've had to deal with reports put together from contributions by multiple authors each using a different version of Office, including some from Japan where even plain text computer code was using a proprietary font that wasn't available on my version of Windows. Importing all the docs to Open Office and a few font substitutions and formating tweaks produced a PDF document acceptable to all the authors. -- George N. White III

On 10/6/21 4:18 PM, Gordon Messmer wrote: I was afraid of that. Dang! Thank you for excellent the tutorial. This looks interesting. M$ put a key into the registry to bypass the new requirements. https://www.bleepingcomputer.com/news/microsoft/how-to-bypass-the-windows...

And I doubt they emulate very many models (they may only emulate 1) of each arch they are handling, and it is pretty unlikely that any of the models they do emulate are what windows 11 wants. On Thu, Oct 7, 2021 at 7:16 AM Patrick O'Callaghan <pocallaghan(a)gmail.com&gt; wrote: > > On Wed, 2021-10-06 at 16:18 -0700, Gordon Messmer wrote: > > On 10/5/21 12:16, ToddAndMargo via users wrote: > > > My host's cpu is not supported. I was hoping for a > > > fake CPU (there are about 20 of them to choose from) > > > would do the trick. > > > > > > That's not possible, because QEMU doesn't emulate the CPU. The host > > CPU > > that you report to the guest VM. > > In fact QEMU can emulate the CPU, even on a completely different > architecture, but of course will can a big performance hot by doing so. > See: > > https://en.wikipedia.org/wiki/QEMU#Operating_modes > > poc > _______________________________________________ > users mailing list -- users(a)lists.fedoraproject.org > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

On 10/7/21 05:16, Patrick O'Callaghan wrote: I thought it was clear that we were discussing qemu in the context of KVM, since it was in the subject, and I didn't have to literally spell out "qemu doesn't emulate the CPU when used with Linux KVM."

ToddAndMargo via users writes: You are fighting a losing battle. I can't think of anything that would prevent Microsoft from removing this bypass at some point in the future, and, for example, result in the system always booting up in safe mode, or refuse to download any updates, or some other shennanigans of that sort. I was able to successfully get Windows 10 to recognize swtmp's emulated TPM 2.0 check. That is eminently doable. This shouldn't be necessary. Not sure what that is. And I was able to get Windows 10 to some up in a VM configured for a secure boot. It came up being deactivated, and wanted me to buy a license, but I have a good hunch as to why. I should have some free time this weekend to hack at it some more. In any case, Windows 10, at least, is fully capable of starting with secure boot. Missing from this laundry list of registry hacks is anything that seems to be related to the CPU vintage, which I suspect will probably be a showstopper for most; at least until the super-smart qemu folks implement emulation of recent Intel CPUs. It remains to be seen how well the performance will be. But, I wouldn't be comfortable updating to Win 11 until it can do it on its own and without any registry hacks. I just do not trust Microsoft not to remove the registry hacks at any point in the future. Especially things like secure boot? No way they'll allow Windows to continue to boot without secure boot forever. It's only a matter of time. There's a moderate chance that I'll be able to convert my existing Win 10 VMs, that already have a working, simulated TPM 2.0 chip to secure boot. And then I'll see what Windows Update thinks of the emulated Haswell-era CPU. I know for a fact that Qemu can emulate both TPM and secure boot sufficiently for Windows 10 to start without any hacks. The only missing piece is the CPU emulation. Just today Windows Update threw up a "This PC cannot currently update to Windows 11, click here to run the health check app", on its own volition, for the first time. So, it looks like Microsoft is rolling out more telemetry via Windows Update, and, I'd guess, that over the next couple of weeks they'll get a lot of telemetry back from their existing user base to see what the results are. I would think they would've already known, a long time ago, how many of the existing Win 10 seats meet the update requirements. It's unclear why the additional step of downloading and installing the health check gizmo is needed. So, it remains to be seen what kind of telemetry Microsoft gets back, and whether enough people will end up replacing their hardware. Microsoft definitely wants everyone to upgrade to Windows 11, but if they see that a large percentage will not I think there's a good chance they'll officially drop some of their requirements, and that's the only path forward that I'll trust. I won't trust the registry hacks.

ToddAndMargo via users writes: I'm aware of that. I just don't trust them. If you note, they put up all sorts of disclaimers and caveat-emptors on that. I don't get the same warm and fuzzy feeling, myself. I think that this is just a temporary stopgap, while Microsoft makes up its mind what to do with this crapstorm. If they decide to pull the plug, they'll just do it, and give a song-and-dance routine about how some feature in the 22H1 update, or something, means that, super-sorry, the hacks don't work. You need TPM and secure boot. And a new CPU. Well, I just piddled away half of my weekend, on this crap. But I think I've got it, by "it" meaning: as much as I can possibly expect to get out of stock qemu. I have Windows 10 21H1 running in a Windows 10 VM that originally traces its lineage to Windows 7, and its digital license. It's running in EFI+secure boot mode, and a clean bill of health in "Security Processor" – both "Encryption" and "Device Attestation" show as "Ready". Earlier this morning (before this long day begun) Settings popped up a new, never before seeing, scary red message (I mentioned this before), telling me that I don't have enough mojo to update to Windows 11, and inviding me to run the "health check" to see if "maybe" I could do something. This is now gone, and replaced by a slightly less scary message. It doesn't outright say that all systems are go in my case. It's just saying something along the lines of "see if your hardware is supported", which is a linked to a Windows page that says, more or less, "We're working on figuring it out". I suspect that Windows is seeing my old CPU, but Microsoft hasn't decided whether to allow upgrades to that configuration yet. But it's now a done deal: yes, you can get qemu to run Windows 10 in secure boot and an emulated TPM 2.0 chip. So, looks like I'm in a holding pattern: to see what Microsoft decides, or maybe our brilliant qemu friends, who are much smarter than me, can figure out how to emulate a CPU to Microsoft's likings. I took notes, and I'll need some time to clean them up, and, dunno, I think I'll post them to the Fedora wiki, after I clean them up. But, TLDR, the way to do this: A) You need a retail Windows license (pretty much the only way to run a licensed Windows in a VM) B) You MUST have a Microsoft account, and your VM registered to your Microsoft account C) My VMs did not have the virtio drivers for Windows. I have no idea if the virtio drivers are signed. You need signed drivers for secure boot. Someone else will have to figure out if a virtio-based Windows 10 VM can be updated in this manner. D) Your VM disk image needs to be in a qcow2 format solely because it makes it easy to snapshot it, and rewing it if you mess up, and end up with a brick. I used a lot of snapshots… E) You need to do the migration in two steps, creating a new VM in each step (pointing to the same disk image), cutting over to the new VM and making sure that Windows settles down in its new home. F) The first VM gets set up using virt manager's default Windows 10 configuration, but with manual configuration that adds a TPM 2.0 TIS chip. Windows 10 will see the chip, and partially support it. It needs to be initialized in Windows, so that Windows gets married to this TPM chip, first, before taking the plunge into EFI and secure boot. It might be possible to do everything in one big jump. But someone else will need to figure that out. G) When everything is ready, use mbr2gpt to create a GPT partition (there are some tricky details to that that required piecing together multiple Google searches), then shut down, and create the 2nd VM, same configuration but using qemu's secure boot firmware. Additionally a manual step is needed to copy the emulated TPM chip's files from the first to the second VM; as well as set up the VGA resolution in the EFI firmware (that was new to me) before secure-booting Windows 10 for the first time. H) It may also be be necessary to set up the secure boot VM's NIC to the same mac address as the first VM's NIC. Virt manager won't let you create VMs with the same NIC, so it's necessary to virsh-edit the first VM's configuration and manually change its Mac address, then put the original one into the EFI VM. Not actually sure if you need to do this, but Windows kept secure-booting successfully but refusing to activate, and I was trying to keep all the changes to the minimym. I finally discovered how to activate it using the former VM's license, and it was fairly straightforward once I figured out the right incantation, in Settings, how to do it. So, it might not be necessary to mess around with MAC addresses, but I can't be sure of that. I can only be sure of what worked for me. So, I'm in a holding pattern now, waiting to see what happens in Microsoft- verse, and if qemu will pull a new CPU rabbit out of their hat. I still have a snapshot of this VM's disk before its secure-boot conversion (even though its licensed has been moved to the EFI VM, but I think I'll be able to transfer it back, if needed), so I have that to go back to. I doubt I'll need to. Although the new VM is notably slow, it feels stable. Big, big thanks to qemu and virt-manager folks.

ToddAndMargo via users writes: No, not because of that. This is something else entirely. Having a retail Windows license tied to a Microsoft account solves all activation issues when migrating an existing Windows license from a BIOS VM to a UEFI VM. I found no way to keep the existing activation during this migration. If you managed to keep your original Windows 7 installation media, from a decade ago, its product key should work. Otherwise you need to tie the license to a Microsoft account.