Re: [PATCH] i386/acpi: restore device paths for pre-5.1 vms

2021-03-25 Thread Igor Mammedov
On Tue, 23 Mar 2021 15:32:23 -0400 "Michael S. Tsirkin" wrote: > On Tue, Mar 23, 2021 at 04:04:11PM +0100, Thomas Lamprecht wrote: > > On 23.03.21 15:55, Vitaly Cheptsov wrote: > > >> 23 марта 2021 г., в 17:48, Michael S. Tsirkin > > >> написал(а): > > >> > > >> The issue is with people who i

Re: [PATCH] i386/acpi: restore device paths for pre-5.1 vms

2021-03-23 Thread Michael S. Tsirkin
On Tue, Mar 23, 2021 at 04:04:11PM +0100, Thomas Lamprecht wrote: > On 23.03.21 15:55, Vitaly Cheptsov wrote: > >> 23 марта 2021 г., в 17:48, Michael S. Tsirkin написал(а): > >> > >> The issue is with people who installed a VM using 5.1 qemu, > >> migrated to 5.2, booted there and set a config on

Re: [PATCH] i386/acpi: restore device paths for pre-5.1 vms

2021-03-23 Thread Thomas Lamprecht
On 23.03.21 15:55, Vitaly Cheptsov wrote: >> 23 марта 2021 г., в 17:48, Michael S. Tsirkin написал(а): >> >> The issue is with people who installed a VM using 5.1 qemu, >> migrated to 5.2, booted there and set a config on a device >> e.g. IP on a NIC. >> They now have a 5.1 machine type but changi

Re: [PATCH] i386/acpi: restore device paths for pre-5.1 vms

2021-03-23 Thread Vitaly Cheptsov
They can simply set the 5.2 VM version in such a case. I do not want to let this legacy hack to be enabled in any modern QEMU VM version, as it violates ACPI specification and makes the life more difficult for various other software like bootloaders and operating systems. > 23 марта 2021 г., в

Re: [PATCH] i386/acpi: restore device paths for pre-5.1 vms

2021-03-23 Thread Michael S. Tsirkin
The issue is with people who installed a VM using 5.1 qemu, migrated to 5.2, booted there and set a config on a device e.g. IP on a NIC. They now have a 5.1 machine type but changing uid back like we do will break these VMs. Unlikley to be common but let's at least create a way for these people to

Re: [PATCH] i386/acpi: restore device paths for pre-5.1 vms

2021-03-22 Thread Vitaly Cheptsov
Hi Michael, That makes little sense in my opinion, these people can simply upgrade the VM version, which apparently looks the right way to do it in my opinion. Best regards, Vitaly > 22 марта 2021 г., в 18:43, Michael S. Tsirkin написал(а): > > On Mon, Mar 01, 2021 at 10:59:18PM +0300, Vitaly

Re: [PATCH] i386/acpi: restore device paths for pre-5.1 vms

2021-03-22 Thread Michael S. Tsirkin
On Mon, Mar 01, 2021 at 10:59:18PM +0300, Vitaly Cheptsov wrote: > After fixing the _UID value for the primary PCI root bridge in > af1b80ae it was discovered that this change updates Windows > configuration in an incompatible way causing network configuration > failure unless DHCP is used. More de

Re: [PATCH] i386/acpi: restore device paths for pre-5.1 vms

2021-03-02 Thread Michael S. Tsirkin
On Mon, Mar 01, 2021 at 10:59:18PM +0300, Vitaly Cheptsov wrote: > After fixing the _UID value for the primary PCI root bridge in > af1b80ae it was discovered that this change updates Windows > configuration in an incompatible way causing network configuration > failure unless DHCP is used. More de

Re: [PATCH] i386/acpi: restore device paths for pre-5.1 vms

2021-03-02 Thread Igor Mammedov
On Mon, 1 Mar 2021 22:59:18 +0300 Vitaly Cheptsov wrote: > After fixing the _UID value for the primary PCI root bridge in > af1b80ae it was discovered that this change updates Windows > configuration in an incompatible way causing network configuration > failure unless DHCP is used. More details

Re: [PATCH] i386/acpi: restore device paths for pre-5.1 vms

2021-03-01 Thread Thomas Lamprecht
On 01.03.21 20:59, Vitaly Cheptsov wrote: > After fixing the _UID value for the primary PCI root bridge in > af1b80ae it was discovered that this change updates Windows > configuration in an incompatible way causing network configuration > failure unless DHCP is used. More details provided on the l

[PATCH] i386/acpi: restore device paths for pre-5.1 vms

2021-03-01 Thread Vitaly Cheptsov
After fixing the _UID value for the primary PCI root bridge in af1b80ae it was discovered that this change updates Windows configuration in an incompatible way causing network configuration failure unless DHCP is used. More details provided on the list: https://lists.gnu.org/archive/html/qemu-deve