On Thu, Jun 08, 2017 at 01:24:01PM +0200, Martin Schwidefsky wrote:
> On Thu, 8 Jun 2017 08:25:31 +0200
> Heiko Carstens wrote:
> > It would be more consistent, since right now a 32-bit ELF file with
> > PT_S390_REQUEST_PGSTE will be exectuted, but the page tables won't have any
> > pgstes. That's
On Thu, 8 Jun 2017 08:25:31 +0200
Heiko Carstens wrote:
> On Thu, Jun 08, 2017 at 07:35:28AM +0200, Martin Schwidefsky wrote:
> > On Wed, 7 Jun 2017 22:47:56 +0200
> > Heiko Carstens wrote:
> > > On Wed, Jun 07, 2017 at 02:34:40PM +0200, Martin Schwidefsky wrote:
> > > > +#define arch_elf_pt
On Thu, Jun 08, 2017 at 07:35:28AM +0200, Martin Schwidefsky wrote:
> On Wed, 7 Jun 2017 22:47:56 +0200
> Heiko Carstens wrote:
> > On Wed, Jun 07, 2017 at 02:34:40PM +0200, Martin Schwidefsky wrote:
> > > +#define arch_elf_pt_proc(ehdr, phdr, elf, interp, state) \
> > > +({
On Wed, 7 Jun 2017 22:47:56 +0200
Heiko Carstens wrote:
> On Wed, Jun 07, 2017 at 02:34:40PM +0200, Martin Schwidefsky wrote:
> > +#define arch_elf_pt_proc(ehdr, phdr, elf, interp, state) \
> > +({ \
> > + struct elf64_hdr *_ehdr = (void
On Wed, Jun 07, 2017 at 02:34:40PM +0200, Martin Schwidefsky wrote:
> +#define arch_elf_pt_proc(ehdr, phdr, elf, interp, state) \
> +({ \
> + struct elf64_hdr *_ehdr = (void *) ehdr;\
> + struct elf64_phdr *_phdr
On Fri, 2 Jun 2017 15:20:33 +0200
Christian Borntraeger wrote:
> On 06/02/2017 12:53 PM, Martin Schwidefsky wrote:
> > On Fri, 2 Jun 2017 12:19:19 +0200
> > Christian Borntraeger wrote:
> >
> >> On 06/02/2017 11:46 AM, Martin Schwidefsky wrote:
> >>> On Fri, 2 Jun 2017 09:02:10 +0200
> >>>
On 06/02/2017 12:53 PM, Martin Schwidefsky wrote:
> On Fri, 2 Jun 2017 12:19:19 +0200
> Christian Borntraeger wrote:
>
>> On 06/02/2017 11:46 AM, Martin Schwidefsky wrote:
>>> On Fri, 2 Jun 2017 09:02:10 +0200
>>> Heiko Carstens wrote:
>>>
On Thu, Jun 01, 2017 at 12:46:51PM +0200, Martin
On 02.06.2017 09:02, Heiko Carstens wrote:
> On Thu, Jun 01, 2017 at 12:46:51PM +0200, Martin Schwidefsky wrote:
>>> Unfortunately, converting all page tables to 4k pgste page tables is
>>> not possible without provoking various race conditions.
>>
>> That is one approach we tried and was found to
On Fri, 2 Jun 2017 12:19:19 +0200
Christian Borntraeger wrote:
> On 06/02/2017 11:46 AM, Martin Schwidefsky wrote:
> > On Fri, 2 Jun 2017 09:02:10 +0200
> > Heiko Carstens wrote:
> >
> >> On Thu, Jun 01, 2017 at 12:46:51PM +0200, Martin Schwidefsky wrote:
> Unfortunately, converting al
On Fri, 2 Jun 2017 12:28:48 +0200
Heiko Carstens wrote:
> On Fri, Jun 02, 2017 at 11:46:47AM +0200, Martin Schwidefsky wrote:
> > On Fri, 2 Jun 2017 09:02:10 +0200
> > Heiko Carstens wrote:
> > > Maybe this is a bit over-simplified, but might work.
> > This is not over-simplified at all, tha
On Fri, Jun 02, 2017 at 11:46:47AM +0200, Martin Schwidefsky wrote:
> On Fri, 2 Jun 2017 09:02:10 +0200
> Heiko Carstens wrote:
> > Maybe this is a bit over-simplified, but might work.
> This is not over-simplified at all, that does work:
Good!
> +struct arch_elf_state {
> +};
> +
> +#define INI
On 06/02/2017 11:46 AM, Martin Schwidefsky wrote:
> On Fri, 2 Jun 2017 09:02:10 +0200
> Heiko Carstens wrote:
>
>> On Thu, Jun 01, 2017 at 12:46:51PM +0200, Martin Schwidefsky wrote:
Unfortunately, converting all page tables to 4k pgste page tables is
not possible without provoking vari
On Fri, 2 Jun 2017 09:02:10 +0200
Heiko Carstens wrote:
> On Thu, Jun 01, 2017 at 12:46:51PM +0200, Martin Schwidefsky wrote:
> > > Unfortunately, converting all page tables to 4k pgste page tables is
> > > not possible without provoking various race conditions.
> >
> > That is one approach we
On Fri, 2 Jun 2017 09:25:54 +0200
Christian Borntraeger wrote:
> On 06/02/2017 09:18 AM, Christian Borntraeger wrote:
> > On 06/02/2017 09:16 AM, Martin Schwidefsky wrote:
> >> On Fri, 2 Jun 2017 09:13:03 +0200
> >> Christian Borntraeger wrote:
> >>
> >>> On 06/02/2017 09:02 AM, Heiko Carste
On 06/02/2017 09:18 AM, Christian Borntraeger wrote:
> On 06/02/2017 09:16 AM, Martin Schwidefsky wrote:
>> On Fri, 2 Jun 2017 09:13:03 +0200
>> Christian Borntraeger wrote:
>>
>>> On 06/02/2017 09:02 AM, Heiko Carstens wrote:
On Thu, Jun 01, 2017 at 12:46:51PM +0200, Martin Schwidefsky wrote
On 06/02/2017 09:16 AM, Martin Schwidefsky wrote:
> On Fri, 2 Jun 2017 09:13:03 +0200
> Christian Borntraeger wrote:
>
>> On 06/02/2017 09:02 AM, Heiko Carstens wrote:
>>> On Thu, Jun 01, 2017 at 12:46:51PM +0200, Martin Schwidefsky wrote:
> Unfortunately, converting all page tables to 4k p
On Fri, 2 Jun 2017 09:13:03 +0200
Christian Borntraeger wrote:
> On 06/02/2017 09:02 AM, Heiko Carstens wrote:
> > On Thu, Jun 01, 2017 at 12:46:51PM +0200, Martin Schwidefsky wrote:
> >>> Unfortunately, converting all page tables to 4k pgste page tables is
> >>> not possible without provoking
On 06/02/2017 09:02 AM, Heiko Carstens wrote:
> On Thu, Jun 01, 2017 at 12:46:51PM +0200, Martin Schwidefsky wrote:
>>> Unfortunately, converting all page tables to 4k pgste page tables is
>>> not possible without provoking various race conditions.
>>
>> That is one approach we tried and was found
On Thu, Jun 01, 2017 at 01:27:28PM +0200, David Hildenbrand wrote:
> An alternative: Have some process that enables PGSTE for all of its
> future children. Fork+execv qemu. However, such a process in between
> will most likely confuse tooling like libvirt when it comes to process ids.
That would b
On Thu, Jun 01, 2017 at 12:46:51PM +0200, Martin Schwidefsky wrote:
> > Unfortunately, converting all page tables to 4k pgste page tables is
> > not possible without provoking various race conditions.
>
> That is one approach we tried and was found to be buggy. The point is that
> you are not allo
Hi Martin,
thanks for having a look at this!
>> However, we
>> might be able to let 2k and 4k page tables co-exist. We only need
>> 4k page tables whenever we want to expose such memory to a guest. So
>> turning on 4k page table allocation at one point and only allowing such
>> memory to go into
On 06/01/2017 12:46 PM, Martin Schwidefsky wrote:
> Hi David,
>
> it is nice to see that you are still working on s390 related topics.
>
> On Mon, 29 May 2017 18:32:00 +0200
> David Hildenbrand wrote:
>
>> Having to enable vm.alloc_pgste globally might not be the best solution.
>> 4k page table
Hi David,
it is nice to see that you are still working on s390 related topics.
On Mon, 29 May 2017 18:32:00 +0200
David Hildenbrand wrote:
> Having to enable vm.alloc_pgste globally might not be the best solution.
> 4k page tables are created for all processes and running QEMU KVM guests
> is m
Having to enable vm.alloc_pgste globally might not be the best solution.
4k page tables are created for all processes and running QEMU KVM guests
is more complicated than it should be.
Unfortunately, converting all page tables to 4k pgste page tables is
not possible without provoking various race
24 matches
Mail list logo
