On Thu, Apr 08, 2021 at 10:46:18AM +0530, Anshuman Khandual wrote:
>
>
> On 4/7/21 10:56 PM, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The struct pages representing a reserved memory region are initialized
> > using reserve_bootmem_range() function. This function is called for each
Adding James here.
+ James Morse
On 4/7/21 10:56 PM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Hi,
>
> These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
> pfn_valid_within() to 1.
That would be really great for arm64 platform as it will save CPU cycles on
many
On 4/7/21 10:56 PM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The struct pages representing a reserved memory region are initialized
> using reserve_bootmem_range() function. This function is called for each
> reserved region just before the memory is freed from memblock to the buddy
>
On 4/7/21 10:56 PM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The intended semantics of pfn_valid() is to verify whether there is a
> struct page for the pfn in question and nothing else.
Should there be a comment affirming this semantics interpretation, above the
generic pfn_valid() in
On 4/7/21 10:56 PM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The arm64's version of pfn_valid() differs from the generic because of two
> reasons:
>
> * Parts of the memory map are freed during boot. This makes it necessary to
> verify that there is actual physical memory that
On Wed, Apr 07, 2021 at 04:31:31PM +0100, Alexandru Elisei wrote:
> On 3/26/21 3:16 AM, Yanan Wang wrote:
> > We currently uniformly permorm CMOs of D-cache and I-cache in function
> > user_mem_abort before calling the fault handlers. If we get concurrent
> > guest faults(e.g. translation faults,
On vcpu reset, we expect all the registers to be brought back
to their initial state, which happens to be a bunch of zeroes.
However, some recent commit broke this, and is now leaving a bunch
of registers (such as a FP state) with whatever was left by the
guest. My bad.
Just zero the whole vcpu
From: Mike Rapoport
The arm64's version of pfn_valid() differs from the generic because of two
reasons:
* Parts of the memory map are freed during boot. This makes it necessary to
verify that there is actual physical memory that corresponds to a pfn
which is done by querying memblock.
*
From: Mike Rapoport
The intended semantics of pfn_valid() is to verify whether there is a
struct page for the pfn in question and nothing else.
Yet, on arm64 it is used to distinguish memory areas that are mapped in the
linear map vs those that require ioremap() to access them.
Introduce a
From: Mike Rapoport
The struct pages representing a reserved memory region are initialized
using reserve_bootmem_range() function. This function is called for each
reserved region just before the memory is freed from memblock to the buddy
page allocator.
The struct pages for MEMBLOCK_NOMAP
From: Mike Rapoport
Hi,
These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
pfn_valid_within() to 1.
The idea is to mark NOMAP pages as reserved in the memory map and restore
the intended semantics of pfn_valid() to designate availability of struct
page for a pfn.
With
On Wed, 7 Apr 2021 15:48:55 +0100, Alexandru Elisei wrote:
> v2 can be found at [1]. Patch #1 in this series is new.
>
> Tested on an odroid-c4 with VHE. vcpu->arch.mdcr_el2 is calculated to be
> 0x84e66. Without this patch, reading MDCR_EL2 after the first vcpu_load() in
>
On 07/04/2021 16:14, Catalin Marinas wrote:
On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote:
On 31/03/2021 19:43, Catalin Marinas wrote:
When a slot is added by the VMM, if it asked for MTE in guest (I guess
that's an opt-in by the VMM, haven't checked the other patches), can we
On Wed, 07 Apr 2021 15:48:56 +0100,
Alexandru Elisei wrote:
>
> Commit 21b6f32f9471 ("KVM: arm64: guest debug, define API headers") added
> the arm64 KVM_GUESTDBG_USE_HW flag for the KVM_SET_GUEST_DEBUG ioctl and
> commit 834bf88726f0 ("KVM: arm64: enable KVM_CAP_SET_GUEST_DEBUG")
> documented
Hi Yanan,
On 3/26/21 3:16 AM, Yanan Wang wrote:
> With a guest translation fault, the memcache pages are not needed if KVM
> is only about to install a new leaf entry into the existing page table.
> And with a guest permission fault, the memcache pages are also not needed
> for a write_fault in
On Wed, 07 Apr 2021 16:13:34 +0100,
Richard Cochran wrote:
>
> On Wed, Apr 07, 2021 at 10:28:44AM +0100, Marc Zyngier wrote:
> > On Tue, 30 Mar 2021 15:54:26 +0100,
> > Marc Zyngier wrote:
> > >
> > > From: Jianyong Wu
> > >
> > > Currently, the ptp_kvm module contains a lot of x86-specific
Hi Yanan,
On 3/26/21 3:16 AM, Yanan Wang wrote:
> We currently uniformly permorm CMOs of D-cache and I-cache in function
> user_mem_abort before calling the fault handlers. If we get concurrent
> guest faults(e.g. translation faults, permission faults) or some really
> unnecessary guest faults
On 07.04.21 17:14, Catalin Marinas wrote:
On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote:
On 31/03/2021 19:43, Catalin Marinas wrote:
When a slot is added by the VMM, if it asked for MTE in guest (I guess
that's an opt-in by the VMM, haven't checked the other patches), can we
On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote:
> On 31/03/2021 19:43, Catalin Marinas wrote:
> > When a slot is added by the VMM, if it asked for MTE in guest (I guess
> > that's an opt-in by the VMM, haven't checked the other patches), can we
> > reject it if it's is going to be
On Wed, Apr 07, 2021 at 10:28:44AM +0100, Marc Zyngier wrote:
> On Tue, 30 Mar 2021 15:54:26 +0100,
> Marc Zyngier wrote:
> >
> > From: Jianyong Wu
> >
> > Currently, the ptp_kvm module contains a lot of x86-specific code.
> > Let's move this code into a new arch-specific file in the same
On Wed, 7 Apr 2021 15:59:37 +0200, Eric Auger wrote:
> Bring some improvements/rationalization over the first version
> of the vgic_init selftests:
>
> - ucall_init is moved in run_cpu()
> - vcpu_args_set is not called as not needed
> - whenever a helper is supposed to succeed, call the non "_"
v2 can be found at [1]. Patch #1 in this series is new.
Tested on an odroid-c4 with VHE. vcpu->arch.mdcr_el2 is calculated to be
0x84e66. Without this patch, reading MDCR_EL2 after the first vcpu_load() in
kvm_arch_vcpu_ioctl_run() returns 0, subsequent reads return 0xe66
(FEAT_TFF and FEAT_SPE
When a VCPU is created, the kvm_vcpu struct is initialized to zero in
kvm_vm_ioctl_create_vcpu(). On VHE systems, the first time
vcpu.arch.mdcr_el2 is loaded on hardware is in vcpu_load(), before it is
set to a sensible value in kvm_arm_setup_debug() later in the run loop. The
result is that KVM
Commit 21b6f32f9471 ("KVM: arm64: guest debug, define API headers") added
the arm64 KVM_GUESTDBG_USE_HW flag for the KVM_SET_GUEST_DEBUG ioctl and
commit 834bf88726f0 ("KVM: arm64: enable KVM_CAP_SET_GUEST_DEBUG")
documented and implemented the flag functionality. Since its introduction,
at no
Hi Eric,
If $SUBJECT started with 'fixup!' and otherwise matched the original
subject then this could be automagically squashed in wherever the
original commit already is.
Anyway,
Reviewed-by: Andrew Jones
Thanks,
drew
On Wed, Apr 07, 2021 at 03:59:37PM +0200, Eric Auger wrote:
> Bring
Bring some improvements/rationalization over the first version
of the vgic_init selftests:
- ucall_init is moved in run_cpu()
- vcpu_args_set is not called as not needed
- whenever a helper is supposed to succeed, call the non "_" version
- helpers do not return -errno, instead errno is checked
On Tue, 16 Mar 2021 12:11:23 +0800, Gavin Shan wrote:
> The series includes several minior improvements to stage-2 page fault
> handler: PATCH[1/2] are cleaning up the code. PATCH[3] don't retrieve
> the memory slot again in the page fault handler to save a bit CPU cycles.
>
> Changelog
>
On Tue, 16 Mar 2021 13:43:38 +,
Keqian Zhu wrote:
>
> The MMIO region of a device maybe huge (GB level), try to use
> block mapping in stage2 to speedup both map and unmap.
>
> Compared to normal memory mapping, we should consider two more
> points when try block mapping for MMIO region:
>
On Wed, Apr 07, 2021 at 12:14:29PM +0200, Auger Eric wrote:
> >> +int _kvm_create_device(struct kvm_vm *vm, uint64_t type, bool test)
> >> +{
> >> + struct kvm_create_device create_dev;
> >> + int ret;
> >> +
> >> + create_dev.type = type;
> >> + create_dev.fd = -1;
> >> + create_dev.flags =
On 31/03/2021 19:43, Catalin Marinas wrote:
On Wed, Mar 31, 2021 at 11:41:20AM +0100, Steven Price wrote:
On 31/03/2021 10:32, David Hildenbrand wrote:
On 31.03.21 11:21, Catalin Marinas wrote:
On Wed, Mar 31, 2021 at 09:34:44AM +0200, David Hildenbrand wrote:
On 30.03.21 12:30, Catalin
Hi Drew,
On 4/6/21 5:09 PM, Andrew Jones wrote:
>
> Hi Eric,
>
> It looks like Marc already picked this patch up, but, FWIW, here's
> a few more comments you may consider.
I will send a fixup patch on top of the one taken my Marc. Few comments
below.
>
> On Mon, Apr 05, 2021 at 06:39:41PM
Hi Eric,
On 2021/2/24 5:06, Eric Auger wrote:
+/*
+ * VFIO_IOMMU_SET_PASID_TABLE - _IOWR(VFIO_TYPE, VFIO_BASE + 18,
+ * struct vfio_iommu_type1_set_pasid_table)
+ *
+ * The SET operation passes a PASID table to the host while the
+ * UNSET operation detaches the one
On Tue, 30 Mar 2021 15:54:26 +0100,
Marc Zyngier wrote:
>
> From: Jianyong Wu
>
> Currently, the ptp_kvm module contains a lot of x86-specific code.
> Let's move this code into a new arch-specific file in the same directory,
> and rename the arch-independent file to ptp_kvm_common.c.
>
>
Hi Eric,
On 2021/2/24 4:56, Eric Auger wrote:
Up to now, when the type was UNMANAGED, we used to
allocate IOVA pages within a reserved IOVA MSI range.
If both the host and the guest are exposed with SMMUs, each
would allocate an IOVA. The guest allocates an IOVA (gIOVA)
to map onto the guest
34 matches
Mail list logo
