On Thu, Nov 26, 2020 at 12:09:13PM -0500, Michael S. Tsirkin wrote: > On Thu, Nov 26, 2020 at 05:34:50PM +0100, Antoine Damhet wrote: > > On Thu, Nov 26, 2020 at 08:29:41AM -0500, Michael S. Tsirkin wrote: > > > On Thu, Nov 26, 2020 at 01:50:12PM +0100, Antoine Damhet wrote: > > > > On Thu, Nov 26, 2020 at 06:09:11AM -0500, Michael S. Tsirkin wrote: > > > > > On Wed, Nov 25, 2020 at 09:13:22PM +0100, Antoine Damhet wrote: > > > > > > On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote: > > > > > > > On Wed, Nov 25, 2020 at 01:32:51PM +0000, Richard W.M. Jones > > > > > > > wrote: > > > > > > > > On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote: > > > > [...] > > > > > Exactly so I ask myself whether it's worth it, their next version > > > will check CPUID and then where are we? > > > > Then I guess they will have to admit that they are purposefully blocking > > VM use and it's not our problem anymore. > > > > > But maybe it's time we just changed all these IDs to e.g. QEMU. > > > We are very far from bochs generated tables by now. > > > > That's a good idea, but I still think they should be user override-able > > (unless you think it would be a heavy maintenance burden, in that case > > you are king in your castle :D ) > > Fundamentally there's a chance that if you get unlucky > with your OEM ID some software somewhere will look for > it and try to activate some vendor specific behaviour. > So giving users full control here isn't all that safe ... > > Question btw, are you also supplying a SLIC table?
In production we do not, I've only toyed with adding a dummy table to see if the `oem_id` and `oem_table_id` there were enough. > > > > > Question is will this cause annoyances with e.g. windows guests? > > > > Windows 10 guests seems unaffected, I cannot say for the other > > versions/servers editions. > > > > > Igor what's your experience with this? > > > > [...] > > > > -- > > Antoine 'xdbob' Damhet > -- Antoine 'xdbob' Damhet
