qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] target/s390x/kvm: Fix problem when running with


From: Thomas Huth
Subject: Re: [Qemu-devel] [PATCH] target/s390x/kvm: Fix problem when running with SELinux under z/VM
Date: Tue, 19 Sep 2017 14:48:50 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

On 19.09.2017 14:38, David Hildenbrand wrote:
> On 18.09.2017 09:43, Christian Borntraeger wrote:
>>
>>
>> On 09/15/2017 04:36 PM, Thomas Huth wrote:
>>> On 29.03.2017 16:25, Christian Borntraeger wrote:
>>>> On 03/29/2017 04:21 PM, Thomas Huth wrote:
>>>>> On 24.03.2017 10:39, Christian Borntraeger wrote:
>>>>>> On 03/24/2017 10:26 AM, Thomas Huth wrote:
>>>>>>> When running QEMU with KVM under z/VM, the memory for the guest
>>>>>>> is allocated via legacy_s390_alloc() since the KVM_CAP_S390_COW
>>>>>>> extension is not supported on z/VM. legacy_s390_alloc() then uses
>>>>>>> mmap(... PROT_EXEC ...) for the guest memory - but this does not
>>>>>>> work when running with SELinux enabled, mmap() fails and QEMU aborts
>>>>>>> with the following error message:
>>>>>>>
>>>>>>>  cannot set up guest memory 's390.ram': Permission denied
>>>>>>>
>>>>>>> Looking at the other allocator function qemu_anon_ram_alloc(), it
>>>>>>> seems like PROT_EXEC is normally not needed for allocating the
>>>>>>> guest RAM, and indeed, the guest also starts successfully under
>>>>>>> z/VM when we remove the PROT_EXEC from the legacy_s390_alloc()
>>>>>>> function. So let's get rid of that flag here to be able to run
>>>>>>> with SELinux under z/VM, too.
>>>>>>
>>>>>> Older z/VM versions do not provide the enhanced suppression on protection
>>>>>> facility, which would result in guest failures as soon as the kernel
>>>>>> starts dirty pages tracking by write protecting the pages via the page
>>>>>> table. Some kernel release back (last time I checked) the PROT_EXEC was 
>>>>>> necessary to prevent the dirty pages tracking from taking place. So this
>>>>>> patch would break KVM in that case.
>>>>>>
>>>>>> Newer z/VMs (e.g. 6.3) do provide ESOP. SO the question is,
>>>>>> why is KVM_CAP_S390_COW not set?
>>>>>
>>>>> I now had another look at this, and seems like the ESOP bit is indeed
>>>>> not set in S390_lowcore.machine_flags here. According to /proc/sysinfo,
>>>>> z/VM is version 6.1.0 here, so I guess that's just too old for ESOP?
>>>>
>>>> Yes, this was introduced with z/VM 6.3
>>>
>>> FWIW, the last version without ESOP, z/VM 6.2, is now end of life,
>>> according to: http://www.vm.ibm.com/techinfo/lpmigr/vmleos.html
>>> ... so I guess we could remove the legacy_s390_alloc() function now?
>>
>>
>> I recently learned that you can buy some extended z/VM support not sure how
>> long this will be available. In addition, ESOP was added with z10, so
>> if we still care about z9 and older then this would break things on
>> very very old boxes.
> 
> I wonder if that is really relevant anymore.
> 
> Existing user on such machines (I doubt there are many) can simply stick
> to QEMU <= 2.10. Or do we actually expect people with such old
> environments to use latest and grates QEMU versions?
> 
> We could add an error message an error out.

Well, as long as the code does not cause any trouble for us, and as long
as there still might be possible users, there is also no real urge to
remove it, is there? I originally thought that all affected systems
would now be EOL, but as Christian pointed out, the z9 BC is not EOL
yet, so I'd say we should at least wait for that point in time before
removing it (I haven't found any public information about extended z/VM
support though, so no clue whether we should really take that into account).

 Thomas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]