qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: David Hildenbrand <david@redhat.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	qemu-devel@nongnu.org
Cc: Cornelia Huck <cohuck@redhat.com>
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	[thread overview]
Message-ID: <09c14d39-8867-0a19-aeeb-f8edcd0df66e@redhat.com> (raw)
In-Reply-To: <6f711dfd-84bc-8683-3655-b836bb5d0a51@redhat.com>

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	other threads:[~2017-09-19 12:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-24  9:26 [Qemu-devel] [PATCH] target/s390x/kvm: Fix problem when running with SELinux under z/VM Thomas Huth
2017-03-24  9:38 ` Cornelia Huck
2017-03-24  9:53   ` Thomas Huth
2017-03-24  9:39 ` Christian Borntraeger
2017-03-24 10:00   ` Thomas Huth
2017-03-29 14:21   ` Thomas Huth
2017-03-29 14:25     ` Christian Borntraeger
2017-09-15 14:36       ` Thomas Huth
2017-09-18  7:43         ` Christian Borntraeger
2017-09-19 12:38           ` David Hildenbrand
2017-09-19 12:48             ` Thomas Huth [this message]
2017-09-19 13:03               ` David Hildenbrand
2017-09-19 13:12                 ` Thomas Huth
2017-09-19 13:14                   ` David Hildenbrand
2017-09-19 13:15                 ` Christian Borntraeger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=09c14d39-8867-0a19-aeeb-f8edcd0df66e@redhat.com \
    --to=thuth@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).