Peter Xu wrote:
> On Fri, Feb 03, 2023 at 10:01:04PM +0100, Juan Quintela wrote:
>> Peter Xu wrote:
>> > On Thu, Feb 02, 2023 at 11:52:21AM +0100, Juan Quintela wrote:
>> >> Peter Xu wrote:
>> >> > Teach QEMU to use /dev/userfaultfd when it existed and fallback to the
>> >> > system call if eith
On Fri, Feb 03, 2023 at 10:01:04PM +0100, Juan Quintela wrote:
> Peter Xu wrote:
> > On Thu, Feb 02, 2023 at 11:52:21AM +0100, Juan Quintela wrote:
> >> Peter Xu wrote:
> >> > Teach QEMU to use /dev/userfaultfd when it existed and fallback to the
> >> > system call if either it's not there or doe
Peter Xu wrote:
> On Thu, Feb 02, 2023 at 11:52:21AM +0100, Juan Quintela wrote:
>> Peter Xu wrote:
>> > Teach QEMU to use /dev/userfaultfd when it existed and fallback to the
>> > system call if either it's not there or doesn't have enough permission.
>> >
>> > Firstly, as long as the app has pe
On Thu, Feb 02, 2023 at 11:52:21AM +0100, Juan Quintela wrote:
> Peter Xu wrote:
> > Teach QEMU to use /dev/userfaultfd when it existed and fallback to the
> > system call if either it's not there or doesn't have enough permission.
> >
> > Firstly, as long as the app has permission to access /dev/
Peter Xu wrote:
> Teach QEMU to use /dev/userfaultfd when it existed and fallback to the
> system call if either it's not there or doesn't have enough permission.
>
> Firstly, as long as the app has permission to access /dev/userfaultfd, it
> always have the ability to trap kernel faults which QEM
Teach QEMU to use /dev/userfaultfd when it existed and fallback to the
system call if either it's not there or doesn't have enough permission.
Firstly, as long as the app has permission to access /dev/userfaultfd, it
always have the ability to trap kernel faults which QEMU mostly wants.
Meanwhile,
