Re: [PATCH RFC 2/5] s390x: implement diag260

[David Hildenbrand]

On 15.07.20 13:34, Heiko Carstens wrote:
> On Wed, Jul 15, 2020 at 01:21:06PM +0200, David Hildenbrand wrote:
>>> At least in v4.1 the kernel will calculate the max address by using
>>> increment size * increment number and then test if *each* increment is
>>> available with tprot.
>>
>> Yes, we do the same in kvm-unit-tests. But it's not sufficient for
>> memory devices.
>>
>> Just because a tprot succeed (for memory belonging to a memory device)
>> does not mean the kernel should silently start to use that memory.
>>
>> Note: memory devices are not just DIMMs that can be mapped to storage
>> increments. The memory might have completely different semantics, that's
>> why they are glued to a managing virtio device.
>>
>> For example: a tprot might succeed on a memory region provided by
>> virtio-mem, this does, however, not mean that the memory can (and
>> should) be used by the guest.
> 
> So, are you saying that even at IPL time there might already be memory
> devices attached to the system? And the kernel should _not_ treat them
> as normal memory?

Sorry if that was unclear. Yes, we can have such devices (including
memory areas) on a cold boot/reboot/kexec. In addition, they might pop
up at runtime (e.g., hotplugging a virtio-mem device). The device is in
charge of exposing that area and deciding what to do with it.

The kernel should never treat them as normal memory (IOW, system RAM).
Not during a cold boot, not during a reboot. The device driver is
responsible for deciding how to use that memory (e.g., add it as system
RAM), and which parts of that memory are actually valid to be used (even
if a tprot might succeed it might not be valid to use just yet - I guess
somewhat similar to doing a tport on a dcss area - AFAIK, you also don't
want to use it like normal memory).

E.g., on x86-64, memory exposed via virtio-mem or virtio-pmem is never
exposed via the e820 map. The only trace that there might be *something*
now/in the future is indicated via ACPI SRAT tables. This takes
currently care of indicating the maximum possible PFN.

-- 
Thanks,

David / dhildenb