Hi Community,
We have observed that the 'ht' feature bit cannot be disabled when QEMU runs
with KVM acceleration.
qemu-system-x86_64 \
--enable-kvm \
-machine q35 \
-cpu host,-ht \
-smp 4 \
-m 4G \
-drive file=rootfs.img,format=raw \
-nographic \
-append 'console=ttyS0 root=/de
y sets
->halted, and not ->stop/stopped as well.
Not sure how best to solve it cleanly. I'll send a revert if I can't
get something working soon.
Thanks,
Nick
On Tue Mar 18, 2025 at 7:09 AM AEST, misanjum wrote:
> Bug Description:
> Encountering a boot failure when launching a KV
Bug Description:
Encountering a boot failure when launching a KVM guest with
'qemu-system-ppc64'. The guest hangs at boot, and the QEMU monitor
crashes.
Reproduction Steps:
# qemu-system-ppc64 --version
QEMU emulator version 9.2.50 (v9.2.0-2799-g0462a32b4f)
Copyright (c) 2003-20
Bug Description:
Encountering a boot failure when launching a KVM guest with
qemu-system-ppc64. The guest hangs at boot, and the QEMU monitor
crashes.
Reproduction Steps:
# qemu-system-ppc64 --version
QEMU emulator version 9.2.50 (v9.2.0-2799-g0462a32b4f)
Copyright (c) 2003-2025 Fabrice
On 21.01.25 21:59, Peter Xu wrote:
On Tue, Jan 21, 2025 at 09:41:55PM +0100, David Hildenbrand wrote:
So far my understanding is that Google that does shared+private guest_memfd
kernel part won't be working on QEMU patches. I raised that to our
management recently, that this would be a good proj
On Tue, Jan 21, 2025 at 09:41:55PM +0100, David Hildenbrand wrote:
> So far my understanding is that Google that does shared+private guest_memfd
> kernel part won't be working on QEMU patches. I raised that to our
> management recently, that this would be a good project for RH to focus on.
>
> I a
This "anon" memory cannot be "shared" with other processes, but
virtio-kernel etc. can just use it.
To "share" the memory with other processes, we'd need memfd/file.
Ah OK, thanks David. Is this the planned long term solution for
vhost-kernel?
I think the basic idea was that the memory backe
t; > field of MachineState. It avoid looking up the machine in phymem.c.
> > >
> > > MachineState::require_guest_memfd is supposed to be set by any VMs
> > > that requires KVM guest memfd as private memory, e.g., TDX VM.
> > >
> > > Signed-off-by:
during RAMBlock allocation.
Memory backend's @guest_memfd is wired with @require_guest_memfd
field of MachineState. It avoid looking up the machine in phymem.c.
MachineState::require_guest_memfd is supposed to be set by any VMs
that requires KVM guest memfd as private memory, e.g., TDX VM.
Si
MBlock allocation.
>
> Memory backend's @guest_memfd is wired with @require_guest_memfd
> field of MachineState. It avoid looking up the machine in phymem.c.
>
> MachineState::require_guest_memfd is supposed to be set by any VMs
> that requires KVM guest memfd as private
On Thu, Jun 6, 2024 at 11:50 AM Chao Du wrote:
>
> This series implements QEMU KVM Guest Debug on RISC-V, with which we
> could debug RISC-V KVM guest from the host side, using software
> breakpoints.
>
> This series is based on riscv-to-apply.next branch and is also
>
This series implements QEMU KVM Guest Debug on RISC-V, with which we
could debug RISC-V KVM guest from the host side, using software
breakpoints.
This series is based on riscv-to-apply.next branch and is also
available at:
https://github.com/Du-Chao/alistair23-qemu/tree/riscv-to-apply.next.0606
On Wed, Jun 5, 2024 at 1:00 PM Chao Du wrote:
>
> This series implements QEMU KVM Guest Debug on RISC-V, with which we
> could debug RISC-V KVM guest from the host side, using software
> breakpoints.
>
> This series is based on riscv-to-apply.next branch and is also
>
The series fixes the issues exposed by the kvm-unit-tests[1]
sprs-migration test.
The sprs DEXCR, HASKKEYR and HASHPKEYR are not registered with
one-reg IDs without which the Qemu is not setting them to their
'previous' value before vcpu run or migration at destination.
The first patch updates th
This series implements QEMU KVM Guest Debug on RISC-V, with which we
could debug RISC-V KVM guest from the host side, using software
breakpoints.
This series is based on riscv-to-apply.next branch and is also
available at:
https://github.com/Du-Chao/alistair23-qemu/tree/riscv-to-apply.next.0605
On Mon, Jun 03 2024, Shivaprasad G Bhat wrote:
> The series fixes the issues exposed by the kvm-unit-tests[1]
> sprs-migration test.
>
> The sprs DEXCR and HASKKEYR are not registered with one-reg IDs
> without which the Qemu is not setting them to their 'previous'
> value during guest migreation
The series fixes the issues exposed by the kvm-unit-tests[1]
sprs-migration test.
The sprs DEXCR and HASKKEYR are not registered with one-reg IDs
without which the Qemu is not setting them to their 'previous'
value during guest migreation at destination.
The two patches in the series take care of
This series implements QEMU KVM Guest Debug on RISC-V, with which we
could debug RISC-V KVM guest from the host side, using software
breakpoints.
This series is based on riscv-to-apply.next branch (v9.0.0) and is also
available at:
https://github.com/Du-Chao/alistair23-qemu/tree/riscv-to
This series implements QEMU KVM Guest Debug on RISC-V, with which we
could debug RISC-V KVM guest from the host side, using software
breakpoints.
This series is based on riscv-to-apply.next branch (v9.0.0) and is also
available at:
https://github.com/Du-Chao/alistair23-qemu/tree/riscv-to
This series implements QEMU KVM Guest Debug on RISC-V, with which we
could debug RISC-V KVM guest from the host side, using software
breakpoints.
This series is based on riscv-to-apply.next branch (v9.0.0) and is also
available at:
https://github.com/Du-Chao/qemu-alistair23/tree/riscv-to
we should wait a bit until we can review this RFC. Otherwise
> >> we
> >> might risk reviewing something that has to be changed later.
> >>
> >>
> >> [1]
> >> https://lore.kernel.org/kvm/20231221095002.7404-1-duc...@eswincomputing.com/
> >
On 2024-05-13 13:36-0700, Sean Christopherson wrote:
> Hmm, a slightly crazy idea (ok, maybe wildly crazy) would be to support
> mapping
> all of guest_memfd into kernel address space, but as USER=1 mappings. I.e.
> don't
> require a carve-out from userspace, but do require CLAC/STAC when access
On Mon, May 13, 2024, James Gowans wrote:
> On Mon, 2024-05-13 at 10:09 -0700, Sean Christopherson wrote:
> > On Mon, May 13, 2024, James Gowans wrote:
> > > On Mon, 2024-05-13 at 08:39 -0700, Sean Christopherson wrote:
> > > > > Sean, you mentioned that you envision guest_memfd also supporting
>
On Mon, 2024-05-13 at 10:09 -0700, Sean Christopherson wrote:
> On Mon, May 13, 2024, James Gowans wrote:
> > On Mon, 2024-05-13 at 08:39 -0700, Sean Christopherson wrote:
> > > > Sean, you mentioned that you envision guest_memfd also supporting
> > > > non-CoCo VMs.
> > > > Do you have some thoug
On Mon, May 13, 2024, James Gowans wrote:
> On Mon, 2024-05-13 at 08:39 -0700, Sean Christopherson wrote:
> > > Sean, you mentioned that you envision guest_memfd also supporting
> > > non-CoCo VMs.
> > > Do you have some thoughts about how to make the above cases work in the
> > > guest_memfd cont
On Mon, 2024-05-13 at 08:39 -0700, Sean Christopherson wrote:
> > Sean, you mentioned that you envision guest_memfd also supporting non-CoCo
> > VMs.
> > Do you have some thoughts about how to make the above cases work in the
> > guest_memfd context?
>
> Yes. The hand-wavy plan is to allow selec
On Mon, May 13, 2024, Patrick Roy wrote:
> For non-CoCo VMs, where memory is not encrypted, and the threat model assumes
> a
> trusted host userspace, we would like to avoid changing the VM model so
> completely. If we adopt CoCo’s approaches where KVM / Userspace touches guest
> memory we would
Hi all,
On 3/9/24 11:14, Mike Rapoport wrote:
>>> >>> With this in mind, what’s the best way to solve getting guest RAM out of
>>> >>> the direct map? Is memfd_secret integration with KVM the way to go, or
>>> >>> should we build a solution on top of guest_memfd, for example via some
>>> >>> flag
ield of MachineState. It avoid looking up the machine in phymem.c.
MachineState::require_guest_memfd is supposed to be set by any VMs
that requires KVM guest memfd as private memory, e.g., TDX VM.
Signed-off-by: Xiaoyao Li
Reviewed-by: David Hildenbrand
Message-ID: <20240320083945.991426
puting.com/
Thanks,
Daniel
On 12/21/23 06:49, Chao Du wrote:
This series implements QEMU KVM Guest Debug on RISC-V. Currently, we can
debug RISC-V KVM guest from the host side, with software breakpoints.
A brief test was done on QEMU RISC-V hypervisor emulator.
A TODO list which will be added late
il we can review this RFC. Otherwise we
> > might risk reviewing something that has to be changed later.
> >
> >
> > [1]
> > https://lore.kernel.org/kvm/20231221095002.7404-1-duc...@eswincomputing.com/
> >
> >
> > Thanks,
> >
> > Dan
uc...@eswincomputing.com/
>
>
> Thanks,
>
> Daniel
>
> On 12/21/23 06:49, Chao Du wrote:
> > This series implements QEMU KVM Guest Debug on RISC-V. Currently, we can
> > debug RISC-V KVM guest from the host side, with software breakpoints.
> >
> > A br
ield of MachineState. It avoid looking up the machine in phymem.c.
MachineState::require_guest_memfd is supposed to be set by any VMs
that requires KVM guest memfd as private memory, e.g., TDX VM.
Signed-off-by: Xiaoyao Li
Reviewed-by: David Hildenbrand
Message-ID: <20240320083945.991426
ield of MachineState. It avoid looking up the machine in phymem.c.
MachineState::require_guest_memfd is supposed to be set by any VMs
that requires KVM guest memfd as private memory, e.g., TDX VM.
Signed-off-by: Xiaoyao Li
Reviewed-by: David Hildenbrand
---
Changes in v4:
- rename &quo
On Fri, 8 Mar 2024 at 18:36, David Matlack wrote:
> I'm not sure if ASI provides a solution to the problem James is trying
> to solve. ASI creates a separate "restricted" address spaces where, yes,
> guest memory can be not mapped. But any access to guest memory is
> still allowed. An access will
On Fri, 8 Mar 2024 15:22:50 -0800, Sean Christopherson wrote:
> On Fri, Mar 08, 2024, James Gowans wrote:
> > We are also aware of ongoing work on guest_memfd. The current
> > implementation unmaps guest memory from VMM address space, but leaves it
> > in the kernel’s direct map. We’re not looking
On Mon, Mar 11, 2024 at 9:26 AM Fuad Tabba wrote:
>
> Hi,
>
> On Fri, Mar 8, 2024 at 9:05 PM Manwaring, Derek wrote:
> >
> > On 2024-03-08 at 10:46-0700, David Woodhouse wrote:
> > > On Fri, 2024-03-08 at 09:35 -0800, David Matlack wrote:
> > > > I think what James is looking for (and what we are
Hi,
On Fri, Mar 8, 2024 at 9:05 PM Manwaring, Derek wrote:
>
> On 2024-03-08 at 10:46-0700, David Woodhouse wrote:
> > On Fri, 2024-03-08 at 09:35 -0800, David Matlack wrote:
> > > I think what James is looking for (and what we are also interested
> > > in), is _eliminating_ the ability to access
On Fri, Mar 08, 2024 at 03:22:50PM -0800, Sean Christopherson wrote:
> On Fri, Mar 08, 2024, James Gowans wrote:
> > However, memfd_secret doesn’t work out the box for KVM guest memory; the
> > main reason seems to be that the GUP path is intentionally disabled for
> > memfd_s
On Fri, Mar 08, 2024 at 03:50:05PM +, Gowans, James wrote:
> Currently when using anonymous memory for KVM guest RAM, the memory all
> remains mapped into the kernel direct map. We are looking at options to
> get KVM guest memory out of the kernel’s direct map as a principled
>
On 2024-03-08 10:36-0700, David Matlack wrote:
> On Fri, Mar 8, 2024 at 8:25 AM Brendan Jackman wrote:
> > On Fri, 8 Mar 2024 at 16:50, Gowans, James wrote:
> > > Our goal is to more completely address the class of issues whose leak
> > > origin is categorized as "Mapped memory" [1].
> >
> > Did
On Fri, Mar 08, 2024, James Gowans wrote:
> However, memfd_secret doesn’t work out the box for KVM guest memory; the
> main reason seems to be that the GUP path is intentionally disabled for
> memfd_secret, so if we use a memfd_secret backed VMA for a memslot then
> KVM is not able
On Fri, Mar 8, 2024 at 8:25 AM Brendan Jackman wrote:
>
> Hi James
>
> On Fri, 8 Mar 2024 at 16:50, Gowans, James wrote:
> > Our goal is to more completely address the class of issues whose leak
> > origin is categorized as "Mapped memory" [1].
>
> Did you forget a link below? I'm interested in h
On 2024-03-08 at 10:46-0700, David Woodhouse wrote:
> On Fri, 2024-03-08 at 09:35 -0800, David Matlack wrote:
> > I think what James is looking for (and what we are also interested
> > in), is _eliminating_ the ability to access guest memory from the
> > direct map entirely. And in general, elimina
On Fri, Mar 08, 2024, David Woodhouse wrote:
> On Fri, 2024-03-08 at 09:35 -0800, David Matlack wrote:
> > I think what James is looking for (and what we are also interested
> > in), is _eliminating_ the ability to access guest memory from the
> > direct map entirely. And in general, eliminate the
On Fri, 2024-03-08 at 09:35 -0800, David Matlack wrote:
> I think what James is looking for (and what we are also interested
> in), is _eliminating_ the ability to access guest memory from the
> direct map entirely. And in general, eliminate the ability to access
> guest memory in as many ways as p
Hello KVM, MM and memfd_secret folks,
Currently when using anonymous memory for KVM guest RAM, the memory all
remains mapped into the kernel direct map. We are looking at options to
get KVM guest memory out of the kernel’s direct map as a principled
approach to mitigating speculative execution
Hi James
On Fri, 8 Mar 2024 at 16:50, Gowans, James wrote:
> Our goal is to more completely address the class of issues whose leak
> origin is categorized as "Mapped memory" [1].
Did you forget a link below? I'm interested in hearing about that
categorisation.
> ... what’s the best way to solve
It avoid looking up the machine in phymem.c.
MachineState::require_guest_memfd is supposed to be set by any VMs
that requires KVM guest memfd as private memory, e.g., TDX VM.
Signed-off-by: Xiaoyao Li
Reviewed-by: David Hildenbrand
---
Changes in v4:
- rename "require_guest_memfd&qu
@require_guest_memfd
field of MachineState. It avoid looking up the machine in phymem.c.
MachineState::require_guest_memfd is supposed to be set by any VMs
that requires KVM guest memfd as private memory, e.g., TDX VM.
Signed-off-by: Xiaoyao Li
---
Reviewed-by: David Hildenbrand
--
Cheers,
David / dhildenb
It avoid looking up the machine in phymem.c.
MachineState::require_guest_memfd is supposed to be set by any VMs
that requires KVM guest memfd as private memory, e.g., TDX VM.
Signed-off-by: Xiaoyao Li
---
Changes in v4:
- rename "require_guest_memfd" to "guest_memfd"
...@eswincomputing.com/
Thanks,
Daniel
On 12/21/23 06:49, Chao Du wrote:
This series implements QEMU KVM Guest Debug on RISC-V. Currently, we can
debug RISC-V KVM guest from the host side, with software breakpoints.
A brief test was done on QEMU RISC-V hypervisor emulator.
A TODO list which will be added later
This series implements QEMU KVM Guest Debug on RISC-V. Currently, we can
debug RISC-V KVM guest from the host side, with software breakpoints.
A brief test was done on QEMU RISC-V hypervisor emulator.
A TODO list which will be added later:
1. HW breakpoints support
2. Test cases
This series is
Synchronize the kvm.h file which enables KVM GUEST DEBUG at QEMU side.
Signed-off-by: Chao Du
---
linux-headers/asm-riscv/kvm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/linux-headers/asm-riscv/kvm.h b/linux-headers/asm-riscv/kvm.h
index 992c5e4071..72942a7aaf 100644
--- a/linux
FD in ram_flags, thus private kvm
guest_memfd will be allocated during RAMBlock allocation.
Memory backend's @require_guest_memfd is wired with
@require_guest_memfd
field of MachineState. MachineState::require_guest_memfd is supposed to
be set by any VMs that requires KVM guest memfd as
ll be allocated during RAMBlock allocation.
Memory backend's @require_guest_memfd is wired with @require_guest_memfd
field of MachineState. MachineState::require_guest_memfd is supposed to
be set by any VMs that requires KVM guest memfd as private memory, e.g.,
TDX VM.
Signed-off-by: Xiaoyao Li
cation.
Memory backend's @require_guest_memfd is wired with @require_guest_memfd
field of MachineState. MachineState::require_guest_memfd is supposed to
be set by any VMs that requires KVM guest memfd as private memory, e.g.,
TDX VM.
Signed-off-by: Xiaoyao Li
I'm confused, why do we need
_memfd is wired with @require_guest_memfd
field of MachineState. MachineState::require_guest_memfd is supposed to
be set by any VMs that requires KVM guest memfd as private memory, e.g.,
TDX VM.
Signed-off-by: Xiaoyao Li
I'm confused, why do we need this if it's going to be the same for
ield of MachineState. MachineState::require_guest_memfd is supposed to
be set by any VMs that requires KVM guest memfd as private memory, e.g.,
TDX VM.
Signed-off-by: Xiaoyao Li
---
backends/hostmem-file.c | 1 +
backends/hostmem-memfd.c | 1 +
backends/hostmem-ram.c | 1 +
backends/hostmem.c
From: Philippe Mathieu-Daudé
Per Anup Patel in [*]:
> Currently, we only support running rv64 guest on rv64 host
> and rv32 guest on rv32 host.
>
> In the future, we might support running rv32 guest on rv64
> host but as of now we don't see a strong push for it.
Therefore, when only using
Per Anup Patel in [*]:
> Currently, we only support running rv64 guest on rv64 host
> and rv32 guest on rv32 host.
>
> In the future, we might support running rv32 guest on rv64
> host but as of now we don't see a strong push for it.
Therefore, when only using the KVM accelerator it is point
On Wed, Apr 19, 2023 at 05:49:55PM -0700, Sean Christopherson wrote:
> On Wed, Apr 19, 2023, Christian Brauner wrote:
> > On Thu, Apr 13, 2023 at 03:28:43PM -0700, Sean Christopherson wrote:
> > > > But if you want to preserve the inode number and device number of the
> > > > relevant tmpfs instanc
On Wed, Apr 19, 2023, Christian Brauner wrote:
> On Thu, Apr 13, 2023 at 03:28:43PM -0700, Sean Christopherson wrote:
> > > But if you want to preserve the inode number and device number of the
> > > relevant tmpfs instance but still report memfd restricted as your
> > > filesystem type
> >
> > Un
On Thu, Apr 13, 2023 at 03:28:43PM -0700, Sean Christopherson wrote:
> On Thu, Apr 13, 2023, Christian Brauner wrote:
> > On Thu, Aug 18, 2022 at 04:24:21PM +0300, Kirill A . Shutemov wrote:
> > > On Wed, Aug 17, 2022 at 10:40:12PM -0700, Hugh Dickins wrote:
> > > > Here's what I would prefer, and
On Fri, Apr 14, 2023, Sean Christopherson wrote:
> On Fri, Apr 14, 2023, Ackerley Tng wrote:
> > Sean Christopherson writes:
> > > if (WARN_ON_ONCE(file->private_data)) {
> > > err = -EEXIST;
> > > goto err_fd;
> > > }
> >
> > Did you intend this as a check that the backin
On Fri, Apr 14, 2023, Ackerley Tng wrote:
> Sean Christopherson writes:
>
> > On Thu, Apr 13, 2023, Christian Brauner wrote:
> > > * by a mount option to tmpfs that makes it act
> > >in this restricted manner then you don't need an ioctl() and can get
> > >away with regular open calls. Su
Sean Christopherson writes:
On Thu, Apr 13, 2023, Christian Brauner wrote:
On Thu, Aug 18, 2022 at 04:24:21PM +0300, Kirill A . Shutemov wrote:
> On Wed, Aug 17, 2022 at 10:40:12PM -0700, Hugh Dickins wrote:
> > Here's what I would prefer, and imagine much easier for you to
maintain;
> > bu
On Thu, Apr 13, 2023, Christian Brauner wrote:
> On Thu, Aug 18, 2022 at 04:24:21PM +0300, Kirill A . Shutemov wrote:
> > On Wed, Aug 17, 2022 at 10:40:12PM -0700, Hugh Dickins wrote:
> > > Here's what I would prefer, and imagine much easier for you to maintain;
> > > but I'm no system designer, an
On Thu, Aug 18, 2022 at 04:24:21PM +0300, Kirill A . Shutemov wrote:
> On Wed, Aug 17, 2022 at 10:40:12PM -0700, Hugh Dickins wrote:
> > On Wed, 6 Jul 2022, Chao Peng wrote:
> > > This is the v7 of this series which tries to implement the fd-based KVM
> > > guest priva
On Tue, Sep 13, 2022, Kirill A. Shutemov wrote:
> On Tue, Sep 13, 2022 at 02:53:25PM +, Sean Christopherson wrote:
> > > > Switching topics, what actually prevents mmapp() on the shim? I tried
> > > > to follow,
> > > > but I don't know these areas well enough.
> > >
> > > It has no f_op->mm
On Tue, Sep 13, 2022 at 02:53:25PM +, Sean Christopherson wrote:
> > > Switching topics, what actually prevents mmapp() on the shim? I tried to
> > > follow,
> > > but I don't know these areas well enough.
> >
> > It has no f_op->mmap, so mmap() will fail with -ENODEV. See do_mmap().
> > (I
On Tue, Sep 13, 2022, Kirill A. Shutemov wrote:
> On Tue, Sep 13, 2022 at 09:44:27AM +, Sean Christopherson wrote:
> > On Thu, Sep 08, 2022, Kirill A. Shutemov wrote:
> > > On Wed, Aug 31, 2022 at 05:24:39PM +0300, Kirill A . Shutemov wrote:
> > > > On Sat, Aug 20, 2022 at 10:15:32PM -0700, Hug
On Tue, Sep 13, 2022 at 09:44:27AM +, Sean Christopherson wrote:
> On Thu, Sep 08, 2022, Kirill A. Shutemov wrote:
> > On Wed, Aug 31, 2022 at 05:24:39PM +0300, Kirill A . Shutemov wrote:
> > > On Sat, Aug 20, 2022 at 10:15:32PM -0700, Hugh Dickins wrote:
> > > > > I will try next week to rewor
On Thu, Sep 08, 2022, Kirill A. Shutemov wrote:
> On Wed, Aug 31, 2022 at 05:24:39PM +0300, Kirill A . Shutemov wrote:
> > On Sat, Aug 20, 2022 at 10:15:32PM -0700, Hugh Dickins wrote:
> > > > I will try next week to rework it as shim to top of shmem. Does it work
> > > > for you?
> > >
> > > Yes,
On Fri, Sep 09, 2022 at 12:11:05PM -0700, Andy Lutomirski wrote:
>
>
> On Fri, Sep 9, 2022, at 7:32 AM, Kirill A . Shutemov wrote:
> > On Thu, Sep 08, 2022 at 09:48:35PM -0700, Andy Lutomirski wrote:
> >> On 8/19/22 17:27, Kirill A. Shutemov wrote:
> >> > On Thu, Aug 18, 2022 at 08:00:41PM -0700,
On Fri, Sep 9, 2022, at 7:32 AM, Kirill A . Shutemov wrote:
> On Thu, Sep 08, 2022 at 09:48:35PM -0700, Andy Lutomirski wrote:
>> On 8/19/22 17:27, Kirill A. Shutemov wrote:
>> > On Thu, Aug 18, 2022 at 08:00:41PM -0700, Hugh Dickins wrote:
>> > > On Thu, 18 Aug 2022, Kirill A . Shutemov wrote:
On Wed, Jul 06, 2022 at 04:20:02PM +0800, Chao Peng wrote:
> This is the v7 of this series which tries to implement the fd-based KVM
> guest private memory. The patches are based on latest kvm/queue branch
> commit:
>
> b9b71f43683a (kvm/queue) KVM: x86/mmu: Buffer nested MMU
>
On Thu, Sep 08, 2022 at 09:48:35PM -0700, Andy Lutomirski wrote:
> On 8/19/22 17:27, Kirill A. Shutemov wrote:
> > On Thu, Aug 18, 2022 at 08:00:41PM -0700, Hugh Dickins wrote:
> > > On Thu, 18 Aug 2022, Kirill A . Shutemov wrote:
> > > > On Wed, Aug 17, 2022 at 10:40:12PM -0700, Hugh Dickins wrote
On 8/24/22 02:41, Chao Peng wrote:
On Tue, Aug 23, 2022 at 04:05:27PM +, Sean Christopherson wrote:
On Tue, Aug 23, 2022, David Hildenbrand wrote:
On 19.08.22 05:38, Hugh Dickins wrote:
On Fri, 19 Aug 2022, Sean Christopherson wrote:
On Thu, Aug 18, 2022, Kirill A . Shutemov wrote:
On We
On 8/19/22 17:27, Kirill A. Shutemov wrote:
On Thu, Aug 18, 2022 at 08:00:41PM -0700, Hugh Dickins wrote:
On Thu, 18 Aug 2022, Kirill A . Shutemov wrote:
On Wed, Aug 17, 2022 at 10:40:12PM -0700, Hugh Dickins wrote:
If your memory could be swapped, that would be enough of a good reason
to mak
On 8/18/22 06:24, Kirill A . Shutemov wrote:
On Wed, Aug 17, 2022 at 10:40:12PM -0700, Hugh Dickins wrote:
On Wed, 6 Jul 2022, Chao Peng wrote:
This is the v7 of this series which tries to implement the fd-based KVM
guest private memory.
Here at last are my reluctant thoughts on this
On Wed, Aug 31, 2022 at 05:24:39PM +0300, Kirill A . Shutemov wrote:
> On Sat, Aug 20, 2022 at 10:15:32PM -0700, Hugh Dickins wrote:
> > > I will try next week to rework it as shim to top of shmem. Does it work
> > > for you?
> >
> > Yes, please do, thanks. It's a compromise between us: the initi
On Fri, Sep 02, 2022 at 06:27:57PM +0800, Chao Peng wrote:
> > + if (flags & MFD_INACCESSIBLE) {
> > + struct file *inaccessible_file;
> > +
> > + inaccessible_file = memfd_mkinaccessible(file);
> > + if (IS_ERR(inaccessible_file)) {
> > + error = P
On Wed, Aug 31, 2022 at 05:24:39PM +0300, Kirill A . Shutemov wrote:
> On Sat, Aug 20, 2022 at 10:15:32PM -0700, Hugh Dickins wrote:
> > > I will try next week to rework it as shim to top of shmem. Does it work
> > > for you?
> >
> > Yes, please do, thanks. It's a compromise between us: the initi
On Wed, Aug 31, 2022 at 10:12:12AM +0100, Fuad Tabba wrote:
> > > Moreover, something which was discussed here before [3], is the
> > > ability to share in-place. For pKVM/arm64, the conversion between
> > > shared and private involves only changes to the stage-2 page tables,
> > > which are contro
On Sat, Aug 20, 2022 at 10:15:32PM -0700, Hugh Dickins wrote:
> > I will try next week to rework it as shim to top of shmem. Does it work
> > for you?
>
> Yes, please do, thanks. It's a compromise between us: the initial TDX
> case has no justification to use shmem at all, but doing it that way
>
7 of this series which tries to implement the fd-based KVM
> > > guest private memory. The patches are based on latest kvm/queue branch
> > > commit:
> > >
> > > b9b71f43683a (kvm/queue) KVM: x86/mmu: Buffer nested MMU
> > > split_desc_cache only by de
On Fri, Aug 26, 2022 at 04:19:25PM +0100, Fuad Tabba wrote:
> Hi,
>
> On Wed, Jul 6, 2022 at 9:24 AM Chao Peng wrote:
> >
> > This is the v7 of this series which tries to implement the fd-based KVM
> > guest private memory. The patches are based on latest
Hi,
On Wed, Jul 6, 2022 at 9:24 AM Chao Peng wrote:
>
> This is the v7 of this series which tries to implement the fd-based KVM
> guest private memory. The patches are based on latest kvm/queue branch
> commit:
>
> b9b71f43683a (kvm/queue) KVM: x86/mmu: Buffer nested MMU
On Sun, Aug 21, 2022 at 11:27:44AM +0100, Matthew Wilcox wrote:
> On Thu, Aug 18, 2022 at 08:00:41PM -0700, Hugh Dickins wrote:
> > tmpfs and hugetlbfs and page cache are designed around sharing memory:
> > TDX is designed around absolutely not sharing memory; and the further
> > uses which Sean fo
On Tue, Aug 23, 2022 at 04:05:27PM +, Sean Christopherson wrote:
> On Tue, Aug 23, 2022, David Hildenbrand wrote:
> > On 19.08.22 05:38, Hugh Dickins wrote:
> > > On Fri, 19 Aug 2022, Sean Christopherson wrote:
> > >> On Thu, Aug 18, 2022, Kirill A . Shutemov wrote:
> > >>> On Wed, Aug 17, 2022
Actually the current version allows you to delay the allocation to a
later time (e.g. page fault time) if you don't call fallocate() on the
private fd. fallocate() is necessary in previous versions because we
treat the existense in the fd as 'private' but in this version we track
private/shared
On Tue, Aug 23, 2022, David Hildenbrand wrote:
> On 19.08.22 05:38, Hugh Dickins wrote:
> > On Fri, 19 Aug 2022, Sean Christopherson wrote:
> >> On Thu, Aug 18, 2022, Kirill A . Shutemov wrote:
> >>> On Wed, Aug 17, 2022 at 10:40:12PM -0700, Hugh Dickins wrote:
> On Wed, 6 Jul 2022, Chao Peng
On 19.08.22 05:38, Hugh Dickins wrote:
> On Fri, 19 Aug 2022, Sean Christopherson wrote:
>> On Thu, Aug 18, 2022, Kirill A . Shutemov wrote:
>>> On Wed, Aug 17, 2022 at 10:40:12PM -0700, Hugh Dickins wrote:
On Wed, 6 Jul 2022, Chao Peng wrote:
But since then, TDX in particular has forced
On Wed, Aug 17, 2022 at 10:27:19AM -0500,
Michael Roth wrote:
> > I think the best approach is to turn KVM_TDX_INIT_MEM_REGION into a generic
> > vCPU-scoped ioctl() that allows userspace to pre-map guest memory.
> > Supporting
> > initializing guest private memory with a source page can be imp
On Thu, Aug 18, 2022 at 08:00:41PM -0700, Hugh Dickins wrote:
> tmpfs and hugetlbfs and page cache are designed around sharing memory:
> TDX is designed around absolutely not sharing memory; and the further
> uses which Sean foresees appear not to need it as page cache either.
>
> Except perhaps f
On Sat, 20 Aug 2022, Kirill A. Shutemov wrote:
>
> Yes, INACCESSIBLE is increase of complexity which you do not want to deal
> with in shmem.c. It get it.
It's not so much that INACCESSIBLE increases the complexity of
memfd/shmem/tmpfs, as that it is completely foreign to it.
And by handling all
On Thu, Aug 18, 2022 at 08:00:41PM -0700, Hugh Dickins wrote:
> On Thu, 18 Aug 2022, Kirill A . Shutemov wrote:
> > On Wed, Aug 17, 2022 at 10:40:12PM -0700, Hugh Dickins wrote:
> > >
> > > If your memory could be swapped, that would be enough of a good reason
> > > to make use of shmem.c: but it
On Thu, Aug 18, 2022, Hugh Dickins wrote:
> On Fri, 19 Aug 2022, Sean Christopherson wrote:
> > On Thu, Aug 18, 2022, Kirill A . Shutemov wrote:
> > > On Wed, Aug 17, 2022 at 10:40:12PM -0700, Hugh Dickins wrote:
> > > > If your memory could be migrated, that would be some reason to use
> > > > fil
On Fri, 19 Aug 2022, Sean Christopherson wrote:
> On Thu, Aug 18, 2022, Kirill A . Shutemov wrote:
> > On Wed, Aug 17, 2022 at 10:40:12PM -0700, Hugh Dickins wrote:
> > > On Wed, 6 Jul 2022, Chao Peng wrote:
> > > But since then, TDX in particular has forced an effort into preventing
> > > (by flag
1 - 100 of 720 matches
Mail list logo
