Le samedi 03 juin 2023 à 16:14 +0200, Thomas Lamprecht a écrit : > Am 01/06/2023 um 11:06 schrieb DERUMIER, Alexandre: > > > Maybe the easiest would be to extract the aes flag out of the > > > grid > > > into > > > the non-advanced part? > > > > > Couldn't be easier to keep aes enable by default in a single model > > (even if it's doesn't match the x86-64 spec). and allow user to > > optin > > disable it. > > The only server where you need to disable aes if for nahelem, and I > > don't think that a lot of users still have this cpu in production. > > (so keeping the aes flag in advanced section make sense). > > Also, user with really old servers, could keep to use kvm64 model, > > where aes is not enabled. > > > I also think that we should not bend to much for Nehalem, and fwiw if > we go for a v2+aes CPU model (which IMO is one of the easies > solutions) > we would only need that for v2, as v3 could always have that enabled > by > default FWIWCT? > > So: > > x86-64-v2 > x86-64-v2-aes (UI default) > x86-64-v3 > > (and that as real models, not just UI fakery) would work, > That's exactly what I have done for the v4 patch series ;)
> But tbh., I'd not be completely against just enabling it for v2 and > warning, > or even erroring, if the VM gets created on a host that doesn't > supports it > (which might be a good idea for any vX level); as Alexandre is right, > a lot of > users needlessly get slower VMs that they could be and production > setups with > a 14 year old CPU are just very unlikely, and they simply can disable > AES again... > I have see that with a lot of my customers, (and also with some benchmark on the net), where admins don't even known what AES is ^_^ _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
