[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/4] s390x/pci: use a reserved ID for the default PCI group
From: |
David Hildenbrand |
Subject: |
Re: [PATCH 1/4] s390x/pci: use a reserved ID for the default PCI group |
Date: |
Fri, 3 Dec 2021 19:21:22 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 |
On 03.12.21 03:25, Matthew Rosato wrote:
> On 12/2/21 6:06 PM, Halil Pasic wrote:
>> On Thu, 2 Dec 2021 12:11:38 -0500
>> Matthew Rosato <mjrosato@linux.ibm.com> wrote:
>>
>>>>
>>>> What happens if we migrate a VM from old to new QEMU? Won't the guest be
>>>> able to observe the change?
>>>>
>>>
>>> Yes, technically -- But # itself is not really all that important, it
>>> is provided from CLP Q PCI FN to be subsequently used as input into Q
>>> PCI FNGRP -- With the fundamental notion being that all functions that
>>> share the same group # share the same group CLP info. Whether the
>>> number is, say, 1 or 5 doesn't matter so much.
>>>
>>> However.. 0xF0 and greater are the only values reserved for hypervisor
>>> use. By using 0x20 we run the risk of accidentally conflating simulated
>>> devices and real hardware, hence the desire to change it.
>>>
>>> Is your concern about a migrated guest with a virtio device trying to do
>>> a CLP QUERY PCI FNGRP using 0x20 on a new QEMU? I suppose we could
>>> modify 'clp_service_call, case CLP_QUERY_PCI_FNGRP' to silently catch
>>> simulated devices trying to use something other than the default group,
>>> e.g.:
>>>
>>> if ((pbdev->fh & FH_SHM_EMUL) &&
>>> (pbdev->zpci_fn.pfgid != ZPCI_DEFAULT_FN_GRP)) {
>>> /* Simulated device MUST have default group */
>>> pbdev->zpci_fn.pfgid = ZPCI_DEFAULT_FN_GRP;
>>> group = s390_group_find(ZPCI_DEFAULT_FN_GRP);
>>> }
>>>
>>> What do you think?
>>
>> Another option, and in my opinion the cleaner one would be to tie this
>> change to a new machine version. That is if a post-change qemu is used
>> in compatibility mode, we would still have the old behavior.
>>
>> What do you think?
>>
>
> The problem there is that the old behavior goes against the architecture
> (group 0x20 could belong to real hardware) and AFAIU assigning this new
> behavior only to a new machine version means we can't fix old stable
> QEMU versions.
>
> Also, wait a minute -- migration isn't even an option right now, it's
> blocked for zpci devices, both passthrough and simulated (see
> aede5d5dfc5f 's390x/pci: mark zpci devices as unmigratable') so I say
> let's just move to a proper default group now before we potentially
> allow migration later.
Perfect, thanks for confirming!
--
Thanks,
David / dhildenb
- [PATCH 2/4] s390x/pci: don't use hard-coded dma range in reg_ioat, (continued)
- [PATCH 2/4] s390x/pci: don't use hard-coded dma range in reg_ioat, Matthew Rosato, 2021/12/02
- [PATCH 1/4] s390x/pci: use a reserved ID for the default PCI group, Matthew Rosato, 2021/12/02
- Re: [PATCH 1/4] s390x/pci: use a reserved ID for the default PCI group, David Hildenbrand, 2021/12/02
- Re: [PATCH 1/4] s390x/pci: use a reserved ID for the default PCI group, Matthew Rosato, 2021/12/02
- Re: [PATCH 1/4] s390x/pci: use a reserved ID for the default PCI group, David Hildenbrand, 2021/12/02
- Re: [PATCH 1/4] s390x/pci: use a reserved ID for the default PCI group, Halil Pasic, 2021/12/02
- Re: [PATCH 1/4] s390x/pci: use a reserved ID for the default PCI group, Matthew Rosato, 2021/12/02
- Re: [PATCH 1/4] s390x/pci: use a reserved ID for the default PCI group, Pierre Morel, 2021/12/03
- Re: [PATCH 1/4] s390x/pci: use a reserved ID for the default PCI group,
David Hildenbrand <=
Re: [PATCH 1/4] s390x/pci: use a reserved ID for the default PCI group, Eric Farman, 2021/12/02
Re: [PATCH 1/4] s390x/pci: use a reserved ID for the default PCI group, Pierre Morel, 2021/12/03