Re: [PATCH v9 3/8] KVM: Add KVM_EXIT_MEMORY_FAULT exit

On Tue, Oct 25, 2022, at 8:13 AM, Chao Peng wrote: > This new KVM exit allows userspace to handle memory-related errors. It > indicates an error happens in KVM at guest memory range [gpa, gpa+size). > The flags includes additional information for userspace to handle the > error. Currently bit 0

Re: [PATCH v8 1/8] mm/memfd: Introduce userspace inaccessible memfd

(please excuse any formatting disasters. my internet went out as I was composing this, and i did my best to rescue it.) On Mon, Sep 19, 2022, at 12:10 PM, Sean Christopherson wrote: > +Will, Marc and Fuad (apologies if I missed other pKVM folks) > > On Mon, Sep 19, 2022, David Hildenbrand

Re: [PATCH v7 00/14] KVM: mm: fd-based approach for supporting KVM guest private memory

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 2

Re: [PATCH v7 00/14] KVM: mm: fd-based approach for supporting KVM guest private memory

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

Re: [PATCH v7 00/14] KVM: mm: fd-based approach for supporting KVM guest private memory

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

Re: [PATCH v7 00/14] KVM: mm: fd-based approach for supporting KVM guest private memory

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

Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory

On 7/21/22 14:19, Sean Christopherson wrote: On Thu, Jul 21, 2022, Gupta, Pankaj wrote: I view it as a performance problem because nothing stops KVM from copying from userspace into the private fd during the SEV ioctl(). What's missing is the ability for userspace to directly initialze the

Re: [PATCH v7 00/14] KVM: mm: fd-based approach for supporting KVM guest private memory

On Wed, Jul 13, 2022, at 3:35 AM, Gupta, Pankaj 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

Re: [PATCH v6 0/8] KVM: mm: fd-based approach for supporting KVM guest private memory

On Tue, Jun 14, 2022 at 12:09 PM Sean Christopherson wrote: > > On Tue, Jun 14, 2022, Andy Lutomirski wrote: > > On Tue, Jun 14, 2022 at 12:32 AM Chao Peng > > wrote: > > > > > > On Thu, Jun 09, 2022 at 08:29:06PM +, Sean Christopherson wrote: > >

Re: [PATCH v6 0/8] KVM: mm: fd-based approach for supporting KVM guest private memory

On Tue, Jun 14, 2022 at 12:32 AM Chao Peng wrote: > > On Thu, Jun 09, 2022 at 08:29:06PM +, Sean Christopherson wrote: > > On Wed, Jun 08, 2022, Vishal Annapurve wrote: > > > > One argument is that userspace can simply rely on cgroups to detect > > misbehaving > > guests, but (a) those types

Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory

On Mon, Apr 25, 2022 at 1:31 PM Sean Christopherson wrote: > > On Mon, Apr 25, 2022, Andy Lutomirski wrote: > > > > > > On Mon, Apr 25, 2022, at 6:40 AM, Chao Peng wrote: > > > On Sun, Apr 24, 2022 at 09:59:37AM -0700, Andy Lutomirski wrote: > > >>

Re: [PATCH v6 4/8] KVM: Extend the memslot to support fd-based private memory

On Fri, May 20, 2022, at 11:31 AM, Sean Christopherson wrote: > But a dedicated KVM ioctl() to add/remove shared ranges would be easy > to implement > and wouldn't necessarily even need to interact with the memslots. It > could be a > consumer of memslots, e.g. if we wanted to disallow

Re: [PATCH v6 4/8] KVM: Extend the memslot to support fd-based private memory

On 5/19/22 08:37, Chao Peng wrote: Extend the memslot definition to provide guest private memory through a file descriptor(fd) instead of userspace_addr(hva). Such guest private memory(fd) may never be mapped into userspace so no userspace_addr(hva) can be used. Instead add another two new

Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory

On Mon, Apr 25, 2022, at 6:40 AM, Chao Peng wrote: > On Sun, Apr 24, 2022 at 09:59:37AM -0700, Andy Lutomirski wrote: >> >> >> 2. Bind the memfile to a VM (or at least to a VM technology). Now it's in >> the initial state appropriate for that VM. >> >

Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory

On Fri, Apr 22, 2022, at 3:56 AM, Chao Peng wrote: > On Tue, Apr 05, 2022 at 06:03:21PM +, Sean Christopherson wrote: >> On Tue, Apr 05, 2022, Quentin Perret wrote: >> > On Monday 04 Apr 2022 at 15:04:17 (-0700), Andy Lutomirski wrote: > Only when the regi

Re: [PATCH v5 04/13] mm/shmem: Restrict MFD_INACCESSIBLE memory against RLIMIT_MEMLOCK

On Tue, Apr 12, 2022, at 7:36 AM, Jason Gunthorpe wrote: > On Fri, Apr 08, 2022 at 08:54:02PM +0200, David Hildenbrand wrote: > >> RLIMIT_MEMLOCK was the obvious candidate, but as we discovered int he >> past already with secretmem, it's not 100% that good of a fit (unmovable >> is worth than

Re: [PATCH v5 04/13] mm/shmem: Restrict MFD_INACCESSIBLE memory against RLIMIT_MEMLOCK

On Thu, Apr 7, 2022, at 9:05 AM, Sean Christopherson wrote: > On Thu, Mar 10, 2022, Chao Peng wrote: >> Since page migration / swapping is not supported yet, MFD_INACCESSIBLE >> memory behave like longterm pinned pages and thus should be accounted to >> mm->pinned_vm and be restricted by

Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory

On Tue, Apr 5, 2022, at 11:30 AM, Sean Christopherson wrote: > On Tue, Apr 05, 2022, Andy Lutomirski wrote: > >> resume guest >> *** host -> hypervisor -> guest *** >> Guest unshares the page. >> *** guest -> hypervisor *** >> Hypervisor r

Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory

On Tue, Apr 5, 2022, at 3:36 AM, Quentin Perret wrote: > On Monday 04 Apr 2022 at 15:04:17 (-0700), Andy Lutomirski wrote: >> >> >> On Mon, Apr 4, 2022, at 10:06 AM, Sean Christopherson wrote: >> > On Mon, Apr 04, 2022, Quentin Perret wrote: >> >>

Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory

On Mon, Apr 4, 2022, at 10:06 AM, Sean Christopherson wrote: > On Mon, Apr 04, 2022, Quentin Perret wrote: >> On Friday 01 Apr 2022 at 12:56:50 (-0700), Andy Lutomirski wrote: >> FWIW, there are a couple of reasons why I'd like to have in-place >> conversions: >&

Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory

On Fri, Apr 1, 2022, at 7:59 AM, Quentin Perret wrote: > On Thursday 31 Mar 2022 at 09:04:56 (-0700), Andy Lutomirski wrote: > To answer your original question about memory 'conversion', the key > thing is that the pKVM hypervisor controls the stage-2 page-tables for > everyone i

Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory

On Wed, Mar 30, 2022, at 10:58 AM, Sean Christopherson wrote: > On Wed, Mar 30, 2022, Quentin Perret wrote: >> On Wednesday 30 Mar 2022 at 09:58:27 (+0100), Steven Price wrote: >> > On 29/03/2022 18:01, Quentin Perret wrote: >> > > Is implicit sharing a thing? E.g., if a guest makes a memory

Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory

On Thu, Mar 10, 2022 at 6:09 AM Chao Peng wrote: > > This is the v5 of this series which tries to implement the fd-based KVM > guest private memory. The patches are based on latest kvm/queue branch > commit: > > d5089416b7fb KVM: x86: Introduce KVM_CAP_DISABLE_QUIRKS2 Can this series be run

Re: [PATCH v4 01/12] mm/shmem: Introduce F_SEAL_INACCESSIBLE

On 2/23/22 04:05, Steven Price wrote: On 23/02/2022 11:49, Chao Peng wrote: On Thu, Feb 17, 2022 at 11:09:35AM -0800, Andy Lutomirski wrote: On Thu, Feb 17, 2022, at 5:06 AM, Chao Peng wrote: On Fri, Feb 11, 2022 at 03:33:35PM -0800, Andy Lutomirski wrote: On 1/18/22 05:21, Chao Peng wrote

Re: [PATCH v4 01/12] mm/shmem: Introduce F_SEAL_INACCESSIBLE

On Thu, Feb 17, 2022, at 5:06 AM, Chao Peng wrote: > On Fri, Feb 11, 2022 at 03:33:35PM -0800, Andy Lutomirski wrote: >> On 1/18/22 05:21, Chao Peng wrote: >> > From: "Kirill A. Shutemov" >> > >> > Introduce a new seal F_SEAL_INACCESSIBLE indicatin

Re: [PATCH v4 04/12] mm/shmem: Support memfile_notifier

On 1/18/22 05:21, Chao Peng wrote: It maintains a memfile_notifier list in shmem_inode_info structure and implements memfile_pfn_ops callbacks defined by memfile_notifier. It then exposes them to memfile_notifier via shmem_get_memfile_notifier_info. We use SGP_NOALLOC in shmem_get_lock_pfn

Re: [PATCH v4 01/12] mm/shmem: Introduce F_SEAL_INACCESSIBLE

On 1/18/22 05:21, Chao Peng wrote: From: "Kirill A. Shutemov" Introduce a new seal F_SEAL_INACCESSIBLE indicating the content of the file is inaccessible from userspace through ordinary MMU access (e.g., read/write/mmap). However, the file content can be accessed via a different mechanism

Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST

On 11/19/21 05:47, Chao Peng wrote: From: "Kirill A. Shutemov" The new seal type provides semantics required for KVM guest private memory support. A file descriptor with the seal set is going to be used as source of guest memory in confidential computing environments such as Intel TDX and AMD

Re: [RFC v2 PATCH 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory

On 11/19/21 05:47, Chao Peng wrote: This RFC series try to implement the fd-based KVM guest private memory proposal described at [1] and an improved 'New Proposal' described at [2]. I generally like this. Thanks!

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

On Sun, Oct 18, 2020 at 8:59 AM Michael S. Tsirkin wrote: > > On Sun, Oct 18, 2020 at 08:54:36AM -0700, Andy Lutomirski wrote: > > On Sun, Oct 18, 2020 at 8:52 AM Michael S. Tsirkin wrote: > > > > > > On Sat, Oct 17, 2020 at 03:24:08PM +0200, Jason A. Donenfel

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

On Sun, Oct 18, 2020 at 8:52 AM Michael S. Tsirkin wrote: > > On Sat, Oct 17, 2020 at 03:24:08PM +0200, Jason A. Donenfeld wrote: > > 4c. The guest kernel maintains an array of physical addresses that are > > MADV_WIPEONFORK. The hypervisor knows about this array and its > > location through

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

On Fri, Oct 16, 2020 at 6:40 PM Jann Horn wrote: > > [adding some more people who are interested in RNG stuff: Andy, Jason, > Theodore, Willy Tarreau, Eric Biggers. also linux-api@, because this > concerns some pretty fundamental API stuff related to RNG usage] > > On Fri, Oct 16, 2020 at 4:33 PM

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

> On Dec 28, 2018, at 6:54 PM, Matthew Wilcox wrote: > >> On Sat, Dec 29, 2018 at 12:12:27AM +, Peter Maydell wrote: >> On Fri, 28 Dec 2018 at 23:16, Andreas Dilger wrot >>> On Dec 28, 2018, at 4:18 AM, Peter Maydell wrote: The problem is that there is no 32-bit API in some cases

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

[sending again, slightly edited, due to email client issues] On Thu, Dec 27, 2018 at 9:25 AM Florian Weimer wrote: > > We have a bit of an interesting problem with respect to the d_off > field in struct dirent. > > When running a 64-bit kernel on certain file systems, notably ext4, > this field

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

> On Dec 27, 2018, at 10:18 AM, Florian Weimer wrote: > > We have a bit of an interesting problem with respect to the d_off > field in struct dirent. > > When running a 64-bit kernel on certain file systems, notably ext4, > this field uses the full 63 bits even for small directories (strace

Re: [Qemu-devel] [PATCH V2 RFC] fixup! virtio: convert to use DMA api

On Wed, Apr 27, 2016 at 7:54 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Wed, Apr 27, 2016 at 07:43:07AM -0700, Andy Lutomirski wrote: >> On Wed, Apr 27, 2016 at 7:38 AM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > On Wed, Apr 27, 2016 at 07:31:43A

Re: [Qemu-devel] [PATCH V2 RFC] fixup! virtio: convert to use DMA api

On Wed, Apr 27, 2016 at 7:38 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Wed, Apr 27, 2016 at 07:31:43AM -0700, Andy Lutomirski wrote: >> On Wed, Apr 27, 2016 at 7:23 AM, Joerg Roedel <j...@8bytes.org> wrote: >> > On Wed, Apr 27, 2016 at 04:37:04PM +

Re: [Qemu-devel] [PATCH V2 RFC] fixup! virtio: convert to use DMA api

On Wed, Apr 27, 2016 at 7:23 AM, Joerg Roedel wrote: > On Wed, Apr 27, 2016 at 04:37:04PM +0300, Michael S. Tsirkin wrote: >> One correction: it's a feature of the device in the system. >> There could be a mix of devices bypassing and not >> bypassing the IOMMU. > > No, it really

[Qemu-devel] [Bug 1574346] [NEW] TCG: mov to segment register is incorrectly emulated for AMD CPUs

Public bug reported: In TCG mode, the effect of: xorl %eax, %eax movl %eax, %gs is to mark the GS segment unusable and set its base to zero. After doing this, reading MSR_GS_BASE will return zero and using a GS prefix in long mode will treat the GS base as zero. This is correct for Intel CPUs

Re: [Qemu-devel] [PATCH RFC] fixup! virtio: convert to use DMA api

On Apr 20, 2016 6:14 AM, "Michael S. Tsirkin" <m...@redhat.com> wrote: > > On Tue, Apr 19, 2016 at 02:07:01PM -0700, Andy Lutomirski wrote: > > On Tue, Apr 19, 2016 at 1:54 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > > > On Tue, Apr 19, 2016

Re: [Qemu-devel] [PATCH RFC] fixup! virtio: convert to use DMA api

On Tue, Apr 19, 2016 at 1:54 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Tue, Apr 19, 2016 at 01:27:29PM -0700, Andy Lutomirski wrote: >> On Tue, Apr 19, 2016 at 1:16 PM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > On Tue, Apr 19, 2016 at 11:01:38A

Re: [Qemu-devel] [PATCH RFC] fixup! virtio: convert to use DMA api

On Tue, Apr 19, 2016 at 1:16 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Tue, Apr 19, 2016 at 11:01:38AM -0700, Andy Lutomirski wrote: >> On Tue, Apr 19, 2016 at 10:49 AM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > On Tue, Apr 19, 2016 at 12:26:44P

Re: [Qemu-devel] [PATCH RFC] fixup! virtio: convert to use DMA api

On Tue, Apr 19, 2016 at 10:49 AM, Michael S. Tsirkin wrote: > On Tue, Apr 19, 2016 at 12:26:44PM -0400, David Woodhouse wrote: >> On Tue, 2016-04-19 at 19:20 +0300, Michael S. Tsirkin wrote: >> > >> > > I thought that PLATFORM served that purpose. Woudn't the host >> > >

Re: [Qemu-devel] [PATCH RFC] fixup! virtio: convert to use DMA api

On Tue, Apr 19, 2016 at 9:09 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Tue, Apr 19, 2016 at 09:02:14AM -0700, Andy Lutomirski wrote: >> On Tue, Apr 19, 2016 at 3:27 AM, Michael S. Tsirkin <m...@redhat.com> wrote: >> > On Mon, Apr 18, 2016 at 12:24:15P

Re: [Qemu-devel] [PATCH RFC] fixup! virtio: convert to use DMA api

On Apr 19, 2016 2:13 AM, "Michael S. Tsirkin" wrote: > > > I guess you are right in that we should split this part out. > What I wanted is really the combination > PASSTHROUGH && !PLATFORM so that we can say "ok we don't > need to guess, this device actually bypasses the IOMMU".

Re: [Qemu-devel] [PATCH RFC] fixup! virtio: convert to use DMA api

On Tue, Apr 19, 2016 at 3:27 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Mon, Apr 18, 2016 at 12:24:15PM -0700, Andy Lutomirski wrote: >> On Mon, Apr 18, 2016 at 11:29 AM, David Woodhouse <dw...@infradead.org> >> wrote: >> > For x86, you *can* ena

Re: [Qemu-devel] [PATCH RFC] fixup! virtio: convert to use DMA api

On Mon, Apr 18, 2016 at 11:29 AM, David Woodhouse wrote: > For x86, you *can* enable virtio-behind-IOMMU if your DMAR tables tell > the truth, and even legacy kernels ought to cope with that. > FSVO 'ought to' where I suspect some of them will actually crash with a > NULL

Re: [Qemu-devel] [PATCH v3 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device

On Sat, Oct 3, 2015 at 4:28 PM, Gabriel L. Somlo wrote: > From: Gabriel Somlo > > Make fw_cfg entries of type "file" available via sysfs. Entries > are listed under /sys/firmware/qemu_fw_cfg/by_key, in folders > named after each entry's selector key. Filename,

Re: [Qemu-devel] [PATCH 10/17] mm: rmap preparation for remap_anon_pages

zero TLB flush during its runtime (it would just require an atomic copy). So should I try to embed a mcopy_atomic inside userfault_write or can I expose it to userland as a standalone new syscall? Or should I do something different? Comments? Thanks, Andrea -- Andy Lutomirski AMA Capital

Re: [Qemu-devel] [PATCH RFC 00/11] qemu: towards virtio-1 host support

On 10/07/2014 07:39 AM, Cornelia Huck wrote: This patchset aims to get us some way to implement virtio-1 compliant and transitional devices in qemu. Branch available at git://github.com/cohuck/qemu virtio-1 I've mainly focused on: - endianness handling - extended feature bits -

[Qemu-devel] [PATCH qemu] i386, linux-headers: Add support for kvm_get_rng_seed

This updates x86's kvm_para.h for the feature bit definition and target-i386/cpu.c for the feature name and default. Signed-off-by: Andy Lutomirski l...@amacapital.net --- linux-headers/asm-x86/kvm_para.h | 2 ++ target-i386/cpu.c| 5 +++-- 2 files changed, 5 insertions(+), 2

Re: [Qemu-devel] [PATCH 00/10] RFC: userfault

On 07/02/2014 09:50 AM, Andrea Arcangeli wrote: Hello everyone, There's a large CC list for this RFC because this adds two new syscalls (userfaultfd and remap_anon_pages) and MADV_USERFAULT/MADV_NOUSERFAULT, so suggestions on changes to the API or on a completely different API if somebody

Re: [Qemu-devel] [PATCH 08/10] userfaultfd: add new syscall to provide memory externalization

On 07/02/2014 09:50 AM, Andrea Arcangeli wrote: Once an userfaultfd is created MADV_USERFAULT regions talks through the userfaultfd protocol with the thread responsible for doing the memory externalization of the process. The protocol starts by userland writing the requested/preferred

Re: [Qemu-devel] Turning off default storage devices?

On Mon, Apr 14, 2014 at 1:15 AM, Markus Armbruster arm...@redhat.com wrote: Peter Crosthwaite peter.crosthwa...@xilinx.com writes: Hi Andy, On Thu, Apr 10, 2014 at 5:55 AM, Andy Lutomirski l...@amacapital.net wrote: Currently, -M q35 boots linux quite a bit slower than the default machine

Re: [Qemu-devel] Turning off default storage devices?

On Wed, Apr 9, 2014 at 8:13 PM, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: On Thu, Apr 10, 2014 at 9:57 AM, Andy Lutomirski l...@amacapital.net wrote: On Wed, Apr 9, 2014 at 4:53 PM, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: Hi Andy, On Thu, Apr 10, 2014 at 5:55 AM

[Qemu-devel] Turning off default storage devices?

Currently, -M q35 boots linux quite a bit slower than the default machine type. This seems to be because it takes a few hundred ms to determine that there's nothing attached to the AHCI controller. In virtio setups, there will probably never be anything attached to the AHCI controller. Would it

Re: [Qemu-devel] Turning off default storage devices?

On Wed, Apr 9, 2014 at 4:53 PM, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: Hi Andy, On Thu, Apr 10, 2014 at 5:55 AM, Andy Lutomirski l...@amacapital.net wrote: Currently, -M q35 boots linux quite a bit slower than the default machine type. This seems to be because it takes a few

[Qemu-devel] Framebuffer corruption in QEMU or Linux's cirrus driver

Running: ./virtme-run --installed-kernel from this virtme commit: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git/commit/?id=2b409a086d15b7a878c7d5204b1f44a6564a341f results in a bunch of missing lines of text once bootup finishes. Pressing enter a few times gradually fixes it. I

Re: [Qemu-devel] Framebuffer corruption in QEMU or Linux's cirrus driver

On Tue, Apr 1, 2014 at 3:09 PM, Andy Lutomirski l...@amacapital.net wrote: Running: ./virtme-run --installed-kernel from this virtme commit: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git/commit/?id=2b409a086d15b7a878c7d5204b1f44a6564a341f results in a bunch of missing lines

[Qemu-devel] Re: [PATCH-V4 0/7] virtio-9p:Introducing security model for VirtFS

Venkateswararao Jujjuri (JV) wrote: This patch series introduces the security model for VirtFS. Brief description of this patch series: It introduces two type of security models for VirtFS. They are: mapped and passthrough. The following is common to both security models. * Client's VFS