Bug 1078607
| Summary: | intel 82576 VF not work in windows 2008 x86 - Code 12 [TestOnly] | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Chao Yang <chayang> | ||||||||
| Component: | qemu-kvm | Assignee: | Eduardo Habkost <ehabkost> | ||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||||
| Severity: | low | Docs Contact: | |||||||||
| Priority: | low | ||||||||||
| Version: | 7.0 | CC: | acathrow, alex.williamson, ehabkost, hhuang, juzhang, michen, virt-maint | ||||||||
| Target Milestone: | rc | Keywords: | TestOnly | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2014-06-13 10:44:42 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | 1080170 | ||||||||||
| Bug Blocks: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Chao Yang
2014-03-20 02:32:20 UTC
This works for me if I set the VF MAC address AND set the CPU to something like Nehalem. IIRC, 32bit Windows is pretty finicky on CPU features required to enable MSI support on assigned devices. Testing on RHEL6, I the requirement to set the VF MAC address is gone since the RHEL6 kernel will assign VFs a random MAC address by default, but also the 82576 VF works in a win2k8 32bit guest regardless of whether I specify a CPU type. Therefore, my guess is that our default CPU has changed in RHEL7 and 32bit Windows is no longer enabling MSI by default. I'll try to get a comparison to see what's different. FWIW, setting the CPU to Nehalem but not the VF MAC changes it from Code 12 to Code 10. Setting the VF MAC but using the default CPU still gives Code 12. Created attachment 876951 [details]
cpu-z cpuid: rhel6 host, no -cpu, MSI works
Created attachment 876952 [details]
cpu-z cpuid: rhel7 host, no -cpu, MSI fails
Created attachment 876953 [details]
cpu-z cpuid: rhel7 host, -cpu cpu64-rhel6, MSI works
IIRC 32bit Windows MSI support requires at least a Pentium III, the default CPU in RHEL7 is Pentium II. Actually, on migration this won't be an issue because the same "-cpu" option will be used on both sides. I don't believe this qualifies as a regression, if the same configuration works the same on both RHEL-6 and RHEL-7: * RHEL-6 with -cpu qemu64, MSI didn't work (as far as I can see) * RHEL-7 with -cpu qemu64, MSI doesn't work, either * RHEL-6 with -cpu cpu64-rhel6, MSI did work * RHEL-7 with -cpu cpu64-rhel6, MSI also works qemu-kvm just have a different default on RHEL-6 and RHEL-7 (making RHEL-7 closer to upstream), but the behavior of each CPU model is the same on RHEL-6 and RHEL-7. Also, the qemu-kvm default doesn't even matter at all: libvirt always use the -cpu option,and we don't support running qemu-kvm directly. As far as I can see on the libvirt RHEL-6.5 code, the libvirt default is "qemu64" and not "cpu64-rhel6". I will run some tests to confirm that. (In reply to Eduardo Habkost from comment #7) > Also, the qemu-kvm default doesn't even matter at all: libvirt always use > the -cpu option,and we don't support running qemu-kvm directly. As far as I > can see on the libvirt RHEL-6.5 code, the libvirt default is "qemu64" and > not "cpu64-rhel6". I will run some tests to confirm that. I was wrong about this: libvirt may run qemu-kvm without any -cpu argument. But it still doesn't make the bug a regression, but just a change of defaults. I have opened bug 1080170, for fixing migration when no -cpu option is provided by libvirt. About this bug, quoting a message I sent by e-mail: If we decide to fix the default later on RHEL-7, we can simply fix it on the "qemu64" CPU model (which is the one libvirt expects to be the default) with the appropriate compat bits. I didn't want to introduce a cpu64-rhel7 CPU model if the upstream default was enough (and we hadn't detected any issues until now!). If qemu64 is the default upstream (and libvirt expects it to be always the case), let's keep qemu64 the default on RHEL-7. If we want the default to look different on RHEL-7, we just need to add qemu64 compat bits to the rhel7 machine-types, instead of creating a new CPU model entry. our qe have tested booting windows 2008 32bit guest with intel 82576 VF assigned on qemu-kvm-1.5.3-59.el7.x86_64. VF in guest worked well and owned an IP. This scenario got passed with default cpu model combined with -M pc, rhel6.5.0, rhel6.4.0, rhel6.3.0, rhel6.2.0, rhel6.1.0, rhel6.0.0 respectively. According to comment12, set this issue as verified. Please note: 1. I'm not very sure we should need to this bz in our rhel7.0 qemu-kvm errata since seems this bz is part of bz[1] 2. be[1] has been verified by our qe. [1]Bug 1080170 - Default CPU model for rhel6.* machine-types is different from RHEL-6 Best Regards, Junyi This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request. |