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
(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 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, Hugh Dickins wrote:
>> > > On Thu, 18 Aug 2
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 patchset
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
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
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:
> >
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
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:
> > >>
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 regis
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 fields
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.
>>
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 registe
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 mlock
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 RLIMIT_
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
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:
>> >>
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:
>&g
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
>
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 access
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 and
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
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
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 since
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 (e.g.
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 S
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!
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
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 whate
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
> 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
(
[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 u
> 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 -
On Wed, Apr 27, 2016 at 7:54 AM, Michael S. Tsirkin 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 wrote:
>> > On Wed, Apr 27, 2016 at 07:31:43AM -0700, Andy Lutomirski wrote:
>> >> O
On Wed, Apr 27, 2016 at 7:38 AM, Michael S. Tsirkin 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 wrote:
>> > On Wed, Apr 27, 2016 at 04:37:04PM +0300, Michael S. Tsirkin wrote:
>> >> One
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 is not. A device
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
On Apr 20, 2016 6:14 AM, "Michael S. Tsirkin" 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 wrote:
> > > On Tue, Apr 19, 2016 at 01:27:29PM -0700, Andy Lutomirski wrote:
> &g
On Tue, Apr 19, 2016 at 1:54 PM, Michael S. Tsirkin 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 wrote:
>> > On Tue, Apr 19, 2016 at 11:01:38AM -0700, Andy Lutomirski wrote:
>> >> On
On Tue, Apr 19, 2016 at 1:16 PM, Michael S. Tsirkin 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 wrote:
>> > On Tue, Apr 19, 2016 at 12:26:44PM -0400, David Woodhouse wrote:
>> >&g
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
>> > > advertise PLATFORM suppor
On Tue, Apr 19, 2016 at 9:09 AM, Michael S. Tsirkin 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 wrote:
>> > On Mon, Apr 18, 2016 at 12:24:15PM -0700, Andy Lutomirski wrote:
>> >> On
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".
What happens when
On Tue, Apr 19, 2016 at 3:27 AM, Michael S. Tsirkin 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
>> wrote:
>> > For x86, you *can* enable virtio-behind-IOMMU if your DMAR tables tell
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 pointer dereference if th
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, selector value,
> and size read-only
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
> -
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 Management, LLC
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
---
linux-headers/asm-x86/kvm_para.h | 2 ++
target-i386/cpu.c| 5 +++--
2 files changed, 5 insertions(+), 2 deletions(-)
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
>
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 someb
On Mon, Apr 14, 2014 at 1:15 AM, Markus Armbruster wrote:
> Peter Crosthwaite writes:
>
>> Hi Andy,
>>
>> On Thu, Apr 10, 2014 at 5:55 AM, Andy Lutomirski wrote:
>>> Currently, -M q35 boots linux quite a bit slower than the default
>>> machine type
On Wed, Apr 9, 2014 at 8:13 PM, Peter Crosthwaite
wrote:
> On Thu, Apr 10, 2014 at 9:57 AM, Andy Lutomirski wrote:
>> On Wed, Apr 9, 2014 at 4:53 PM, Peter Crosthwaite
>> wrote:
>>> Hi Andy,
>>>
>>> On Thu, Apr 10, 2014 at 5:55 AM, Andy Lutomirski
>
On Wed, Apr 9, 2014 at 4:53 PM, Peter Crosthwaite
wrote:
> Hi Andy,
>
> On Thu, Apr 10, 2014 at 5:55 AM, Andy Lutomirski wrote:
>> 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
>
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
On Tue, Apr 1, 2014 at 3:09 PM, Andy Lutomirski 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 bun
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 do
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 deter
60 matches
Mail list logo