CVMSEG Emulation

CVMSEG Emulation

[Christopher Wrogg]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

<https://matrix.to/#/!xtcopKjjucUQThGiEn:matrix.org/$16705104253940lCHrT:matrix.org?via=matrix.org&via=matrix.im&via=matrix.alindner.org>
In userspace emulation how do I make a set of addresses always valid and
initialized to 0 even though the process does not map it in? In particular
I want to map the CVMSEG for Cavium qemu-mips64 and qemu-mipsn32. The
addresses would be 0xFFFFFFFFFFFF8000 - 0xFFFFFFFFFFFFBFFF. I've looked at
target_mmap but it can't handle addresses that large. The lack of an
emulated mmu for 64 bit guests is going to be a problem.

[-- Attachment #2: Type: text/html, Size: 735 bytes --]

Re: CVMSEG Emulation

[Jiaxun Yang]

Hi,

This address range is located in KSEG3… Doesn’t seems to be a good location
for userspace program.

I think you have two options to make target_mmap work, the first would be rising
TARGET_VIRT_ADDR_SPACE_BITS to 64 bit. That may break some user space
applications storing pointer tags on higher bits.

The second would be mask CVMSEG base with TARGET_VIRT_ADDR_SPACE_BITS
before mmap, As higher VM address bits will be dropped when addressing guest VM,
that should provide a similar behaviour. Though you’ll have multiple alias for CVMSEG in
memory and application will be able to access CVMSEG with bits higher than
TARGET_VIRT_ADDR_SPACE_BITS set to any value. Don’t know if it will break anything,
AFAIK normal applications won't use this range.

Thanks
- Jiaxun 


> 2022年12月8日 15:08，Christopher Wrogg <cwrogg@umich.edu> 写道：
> 
> In userspace emulation how do I make a set of addresses always valid and initialized to 0 even though the process does not map it in? In particular I want to map the CVMSEG for Cavium qemu-mips64 and qemu-mipsn32. The addresses would be 0xFFFFFFFFFFFF8000 - 0xFFFFFFFFFFFFBFFF. I've looked at target_mmap but it can't handle addresses that large. The lack of an emulated mmu for 64 bit guests is going to be a problem.

Re: CVMSEG Emulation

[Christopher Wrogg]

[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]

I tried both.

Option 1
    What I did:
        #undef TARGET_VIRT_ADDR_SPACE_BITS and #define
TARGET_VIRT_ADDR_SPACE_BITS 64
    The Result:
        perror reports "Cannot allocate memory"
Option 2:
    What I did:
        TARGET_VIRT_ADDR_SPACE_BITS for me is 30 so I masked by 0x3FFFFFFF
    The Result:
        The segfault persists and gdb reports the memory as inaccessible.

On Thu, Dec 8, 2022 at 4:55 PM Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:

>
> Hi,
>
> This address range is located in KSEG3… Doesn’t seems to be a good location
> for userspace program.
>
> I think you have two options to make target_mmap work, the first would be
> rising
> TARGET_VIRT_ADDR_SPACE_BITS to 64 bit. That may break some user space
> applications storing pointer tags on higher bits.
>
> The second would be mask CVMSEG base with TARGET_VIRT_ADDR_SPACE_BITS
> before mmap, As higher VM address bits will be dropped when addressing
> guest VM,
> that should provide a similar behaviour. Though you’ll have multiple alias
> for CVMSEG in
> memory and application will be able to access CVMSEG with bits higher than
> TARGET_VIRT_ADDR_SPACE_BITS set to any value. Don’t know if it will break
> anything,
> AFAIK normal applications won't use this range.
>
> Thanks
> - Jiaxun
>
>
> > 2022年12月8日 15:08，Christopher Wrogg <cwrogg@umich.edu> 写道：
> >
> > In userspace emulation how do I make a set of addresses always valid and
> initialized to 0 even though the process does not map it in? In particular
> I want to map the CVMSEG for Cavium qemu-mips64 and qemu-mipsn32. The
> addresses would be 0xFFFFFFFFFFFF8000 - 0xFFFFFFFFFFFFBFFF. I've looked at
> target_mmap but it can't handle addresses that large. The lack of an
> emulated mmu for 64 bit guests is going to be a problem.
>
>

[-- Attachment #2: Type: text/html, Size: 2409 bytes --]

Re: CVMSEG Emulation

[Jiaxun Yang]

> 2022年12月9日 17:44，Christopher Wrogg <cwrogg@umich.edu> 写道：
> 
> I tried both.
> 
> Option 1 
>     What I did:
>         #undef TARGET_VIRT_ADDR_SPACE_BITS and #define TARGET_VIRT_ADDR_SPACE_BITS 64
>     The Result:
>         perror reports "Cannot allocate memory"
> Option 2: 
>     What I did:
>         TARGET_VIRT_ADDR_SPACE_BITS for me is 30 so I masked by 0x3FFFFFFF
>     The Result:
>         The segfault persists and gdb reports the memory as inaccessible.

Hmm this looks wired for me, by no chance TARGET_VIRT_ADDR_SPACE_BITS for MIPS
can be 30, on N64 ABI build it should be 48 and 32 for N32 or O32 build.

It is defined in target/mips/cpu-param.h .

Thanks.

> 
> On Thu, Dec 8, 2022 at 4:55 PM Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
> 
> Hi,
> 
> This address range is located in KSEG3… Doesn’t seems to be a good location
> for userspace program.
> 
> I think you have two options to make target_mmap work, the first would be rising
> TARGET_VIRT_ADDR_SPACE_BITS to 64 bit. That may break some user space
> applications storing pointer tags on higher bits.
> 
> The second would be mask CVMSEG base with TARGET_VIRT_ADDR_SPACE_BITS
> before mmap, As higher VM address bits will be dropped when addressing guest VM,
> that should provide a similar behaviour. Though you’ll have multiple alias for CVMSEG in
> memory and application will be able to access CVMSEG with bits higher than
> TARGET_VIRT_ADDR_SPACE_BITS set to any value. Don’t know if it will break anything,
> AFAIK normal applications won't use this range.
> 
> Thanks
> - Jiaxun 
> 
> 
> > 2022年12月8日 15:08，Christopher Wrogg <cwrogg@umich.edu> 写道：
> > 
> > In userspace emulation how do I make a set of addresses always valid and initialized to 0 even though the process does not map it in? In particular I want to map the CVMSEG for Cavium qemu-mips64 and qemu-mipsn32. The addresses would be 0xFFFFFFFFFFFF8000 - 0xFFFFFFFFFFFFBFFF. I've looked at target_mmap but it can't handle addresses that large. The lack of an emulated mmu for 64 bit guests is going to be a problem.
> 

Re: CVMSEG Emulation

[Peter Maydell]

On Fri, 9 Dec 2022 at 21:03, Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>
>
>
> > 2022年12月9日 17:44，Christopher Wrogg <cwrogg@umich.edu> 写道：
> >
> > I tried both.
> >
> > Option 1
> >     What I did:
> >         #undef TARGET_VIRT_ADDR_SPACE_BITS and #define TARGET_VIRT_ADDR_SPACE_BITS 64
> >     The Result:
> >         perror reports "Cannot allocate memory"
> > Option 2:
> >     What I did:
> >         TARGET_VIRT_ADDR_SPACE_BITS for me is 30 so I masked by 0x3FFFFFFF
> >     The Result:
> >         The segfault persists and gdb reports the memory as inaccessible.
>
> Hmm this looks wired for me, by no chance TARGET_VIRT_ADDR_SPACE_BITS for MIPS
> can be 30, on N64 ABI build it should be 48 and 32 for N32 or O32 build.
>
> It is defined in target/mips/cpu-param.h .

For 32-bit user-mode we currently set it to 31, on the theory that userspace
only gets access to the bottom half of the address space.

-- PMM

Re: CVMSEG Emulation

[Christopher Wrogg]

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

I am getting the 48 bits value on 64 bit hosts. Having said that, I still
have the two problems above with the suggested fixes.

On Mon, Dec 12, 2022 at 7:03 AM Peter Maydell <peter.maydell@linaro.org>
wrote:

> On Fri, 9 Dec 2022 at 21:03, Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
> >
> >
> >
> > > 2022年12月9日 17:44，Christopher Wrogg <cwrogg@umich.edu> 写道：
> > >
> > > I tried both.
> > >
> > > Option 1
> > >     What I did:
> > >         #undef TARGET_VIRT_ADDR_SPACE_BITS and #define
> TARGET_VIRT_ADDR_SPACE_BITS 64
> > >     The Result:
> > >         perror reports "Cannot allocate memory"
> > > Option 2:
> > >     What I did:
> > >         TARGET_VIRT_ADDR_SPACE_BITS for me is 30 so I masked by
> 0x3FFFFFFF
> > >     The Result:
> > >         The segfault persists and gdb reports the memory as
> inaccessible.
> >
> > Hmm this looks wired for me, by no chance TARGET_VIRT_ADDR_SPACE_BITS
> for MIPS
> > can be 30, on N64 ABI build it should be 48 and 32 for N32 or O32 build.
> >
> > It is defined in target/mips/cpu-param.h .
>
> For 32-bit user-mode we currently set it to 31, on the theory that
> userspace
> only gets access to the bottom half of the address space.
>
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 1852 bytes --]

CVMSEG Emulation

[Christopher Wrogg]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

Was wondering if there was a follow up to this. Just a recap but I am
trying to map 0xFFFFFFFFFFFF8000 - 0xFFFFFFFFFFFFBFFF into a userspace
process's virtual address space. It falls squarely in KSEG3.

Here is what I have tried

Attempt 1
    What I did:
        #undef TARGET_VIRT_ADDR_SPACE_BITS and #define
TARGET_VIRT_ADDR_SPACE_BITS 64
    The Result:
        perror reports "Cannot allocate memory"
Attempt 2:
    What I did:
        TARGET_VIRT_ADDR_SPACE_BITS for me is 48 on amd64 so I masked by
0xFFFFFFFFFFFF
    The Result:
        perror reports "Cannot allocate memory"

[-- Attachment #2: Type: text/html, Size: 793 bytes --]