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
23 matches
Mail list logo
