RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1945666 - 9.0: x86 machine types
Summary: 9.0: x86 machine types
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: qemu-kvm
Version: 9.0
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: beta
: ---
Assignee: Dr. David Alan Gilbert
QA Contact: jingzhao
URL:
Whiteboard:
: 2022601 (view as bug list)
Depends On:
Blocks: 1947015 1998940 2022604 2031043 2042850
TreeView+ depends on / blocked
 
Reported: 2021-04-01 15:14 UTC by Dr. David Alan Gilbert
Modified: 2022-05-17 12:26 UTC (History)
23 users (show)

Fixed In Version: qemu-kvm-6.2.0-5.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-05-17 12:23:22 UTC
Type: Bug
Target Upstream Version:
Embargoed:
jinzhao: needinfo-
jinzhao: needinfo-

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Gitlab redhat/centos-stream/src qemu-kvm merge_requests 61 0 None None None 2022-01-12 18:52:12 UTC
Red Hat Product Errata RHBA-2022:2307 0 None None None 2022-05-17 12:24:06 UTC

Comment 5 Dr. David Alan Gilbert 2021-08-03 13:00:49 UTC 
9.0 beta was the same as 8.5; so we go this for free;
but 9.0 is now getting rebased, so we now need to chase the machine type to update the machine type to match upstream changes.
Comment 7 John Ferlan 2021-12-10 21:28:05 UTC 
*** Bug 2022601 has been marked as a duplicate of this bug. ***
Comment 8 Daniel Berrangé 2021-12-16 12:15:12 UTC 
Note historically the RHEL x86 machine types have overridden some of the SMBIOS defaults:

    pcmc->smbios_stream_product = "RHEL-AV";
    pcmc->smbios_stream_version = "8.5.0";

In RHEL-9 there is no separate RHEL-AV product stream any more, so it is likely that we should change SMBIOS to say just 'RHEL' for the 9.x series machine types.

This will likely require an alert to the Windows driver maintainers since they match on some of the SMBIOS data.

See also corresponding question for 8.6 machine types https://bugzilla.redhat.com/show_bug.cgi?id=2031035#c3
Comment 10 Dr. David Alan Gilbert 2022-01-11 18:55:48 UTC 
Yan: See Dan's comment 8;  if we change the smbios_stream_product on 9.0 to "HREL" rather than -AV, what will break for the windows drivers?
What's your preference?
Comment 12 Dr. David Alan Gilbert 2022-01-12 13:37:27 UTC 
For now I'll set it as:

+    pcmc->smbios_stream_product = "RHEL-AV";
+    pcmc->smbios_stream_version = "9.0.0";

but please shout if you think we can remove the -AV or if this will cause a problem.
Comment 14 Qianqian Zhu 2022-01-13 05:05:09 UTC 
Hi,

On windows update we apply 'HardwareID-6: Manufacturer + SKU Number + Baseboard_Manufacturer + Baseboard_Product' listed here: https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/using-chids
And I don't see any risk for the change, we will get proper HardwareID from the host OS when we submit it, whatever it is.

Regards,
Qianqian
Comment 15 Qianqian Zhu 2022-01-13 05:15:47 UTC 
Additionally, current change does not influence virtio-win drivers on Windows Update because RHEL8.6/RHEL9.0 are all NOT released, we don't have existed submission on Windows Update, so we can get proper HardwareID later than your change.

If you have any change on released product: RHEL-AV 8.4/8.5, please let us know. We will need to change the information on Windows Update accordingly.

Thanks,
Qianqian
Comment 19 Dr. David Alan Gilbert 2022-01-13 14:05:18 UTC 
(In reply to Qianqian Zhu from comment #15)
> Additionally, current change does not influence virtio-win drivers on
> Windows Update because RHEL8.6/RHEL9.0 are all NOT released, we don't have
> existed submission on Windows Update, so we can get proper HardwareID later
> than your change.
> 
> If you have any change on released product: RHEL-AV 8.4/8.5, please let us
> know. We will need to change the information on Windows Update accordingly.

So at the moment I've kept it the same as RHEL-AV;  what's your preference for 9.0 - do you
want 'RHEL' or 'RHEL-AV' ?
What happens to an image that was installed on one version and then used on a newer version?

Dave

> 
> Thanks,
> Qianqian
Comment 20 Daniel Berrangé 2022-01-13 14:19:07 UTC 
(In reply to Qianqian Zhu from comment #14)
> Hi,
> 
> On windows update we apply 'HardwareID-6: Manufacturer + SKU Number +
> Baseboard_Manufacturer + Baseboard_Product' listed here:
> https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/using-
> chids
> And I don't see any risk for the change, we will get proper HardwareID from
> the host OS when we submit it, whatever it is.

So IIUC, you're saying that every time we have a RHEL release you register an additional set of matches with windows update. So any previous version HW strings registered will carry on working, and the new version HW strings can be whatever we want them to be.

With that, I'd say we should use just "RHEL" for the rhel9.x.x machine types
Comment 21 Qianqian Zhu 2022-01-14 02:40:47 UTC 
(In reply to Dr. David Alan Gilbert from comment #19)
> (In reply to Qianqian Zhu from comment #15)
> > Additionally, current change does not influence virtio-win drivers on
> > Windows Update because RHEL8.6/RHEL9.0 are all NOT released, we don't have
> > existed submission on Windows Update, so we can get proper HardwareID later
> > than your change.
> > 
> > If you have any change on released product: RHEL-AV 8.4/8.5, please let us
> > know. We will need to change the information on Windows Update accordingly.
> 
> So at the moment I've kept it the same as RHEL-AV;  what's your preference
> for 9.0 - do you
> want 'RHEL' or 'RHEL-AV' ?

It could be 'RHEL' from my perspective.

> What happens to an image that was installed on one version and then used on
> a newer version?

We will register all latest RHEL(or AV) releases to Windows Update for new drivers, now we have AV8.4/AV8.5 on Windows Update, and after RHEL8.6/RHEL9.0 released we will add them to Windows Update too.
So if the image running on newer version I assume they will just get new drivers.

> 
> Dave
> 
> > 
> > Thanks,
> > Qianqian
Comment 22 Qianqian Zhu 2022-01-14 02:41:53 UTC 
(In reply to Daniel Berrangé from comment #20)
> (In reply to Qianqian Zhu from comment #14)
> > Hi,
> > 
> > On windows update we apply 'HardwareID-6: Manufacturer + SKU Number +
> > Baseboard_Manufacturer + Baseboard_Product' listed here:
> > https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/using-
> > chids
> > And I don't see any risk for the change, we will get proper HardwareID from
> > the host OS when we submit it, whatever it is.
> 
> So IIUC, you're saying that every time we have a RHEL release you register
> an additional set of matches with windows update. So any previous version HW
> strings registered will carry on working, and the new version HW strings can
> be whatever we want them to be.

Correct.

> 
> With that, I'd say we should use just "RHEL" for the rhel9.x.x machine types

Agree.
Comment 24 Dr. David Alan Gilbert 2022-01-17 11:40:38 UTC 
(In reply to Qianqian Zhu from comment #22)
> (In reply to Daniel Berrangé from comment #20)
> > (In reply to Qianqian Zhu from comment #14)
> > > Hi,
> > > 
> > > On windows update we apply 'HardwareID-6: Manufacturer + SKU Number +
> > > Baseboard_Manufacturer + Baseboard_Product' listed here:
> > > https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/using-
> > > chids
> > > And I don't see any risk for the change, we will get proper HardwareID from
> > > the host OS when we submit it, whatever it is.
> > 
> > So IIUC, you're saying that every time we have a RHEL release you register
> > an additional set of matches with windows update. So any previous version HW
> > strings registered will carry on working, and the new version HW strings can
> > be whatever we want them to be.
> 
> Correct.
> 
> > 
> > With that, I'd say we should use just "RHEL" for the rhel9.x.x machine types
> 
> Agree.

OK, new version coming up.
Comment 25 Dr. David Alan Gilbert 2022-01-17 12:15:35 UTC 
merge request branch updated; now shows:



Handle 0x0200, DMI type 2, 15 bytes
Base Board Information
        Manufacturer: Red Hat
        Product Name: RHEL
        Version: RHEL-9.0.0 PC (Q35 + ICH9, 2009)
        Serial Number: Not Specified
        Asset Tag: Not Specified
        Features:
                Board is a hosting board

Handle 0x0200, DMI type 2, 15 bytes
Base Board Information
        Manufacturer: Red Hat
        Product Name: RHEL-AV
        Version: RHEL-8.6.0 PC (Q35 + ICH9, 2009)
        Serial Number: Not Specified
        Asset Tag: Not Specified
        Features:
                Board is a hosting board
Comment 27 Yanan Fu 2022-01-27 10:30:29 UTC 
QE bot(pre verify): Set 'Verified:Tested,SanityOnly' as gating/tier1 test pass.
Comment 34 errata-xmlrpc 2022-05-17 12:23:22 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: qemu-kvm), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:2307
Note You need to log in before you can comment on or make changes to this bug.