On 12/12/18 8:50 AM, Kees Cook wrote:
> On Mon, Dec 10, 2018 at 7:41 PM wrote:
>>
>> From: Yulei Zhang
>>
>> Early this year we spot there may be two issues in kernel
>> kfifo.
>>
>> One is reported by Xiao Guangrong to linux kernel.
>> htt
On 07/27/2018 11:46 PM, Paolo Bonzini wrote:
We are currently cutting hva_to_pfn_fast short if we do not want an
immediate exit, which is represented by !async && !atomic. However,
this is unnecessary, and __get_user_pages_fast is *much* faster
because the regular get_user_pages takes pmd_loc
set_spte().
Signed-off-by: Lan Tianyu
Looks good, but I'd like a second opinion. Guangrong, Junaid, can you
review this?
It looks good to me.
Reviewed-by: Xiao Guangrong
BTW, the @intel box is not accessible to me now. ;)
Hi,
Currently, there is no read barrier between reading the index
(kfifo.in) and fetching the real data from the fifo.
I am afraid that will cause the vfifo is observed as not empty
however the data is not actually ready for read. Right?
Thanks!
On 02/09/2018 08:42 PM, Paolo Bonzini wrote:
On 09/02/2018 04:22, Xiao Guangrong wrote:
That is a good question... :)
This case (with KVM_MEMSLOT_INVALID is set) can be easily constructed,
userspace should avoid this case by itself (avoiding vCPU accessing the
memslot which is being
On 02/08/2018 06:31 PM, Paolo Bonzini wrote:
On 08/02/2018 09:57, Xiao Guangrong wrote:
Maybe it should return RET_PF_EMULATE, which would cause an emulation
failure and then an exit with KVM_EXIT_INTERNAL_ERROR.
So the root cause is that a running vCPU accessing the memory whose memslot
is
On 02/07/2018 10:16 PM, Paolo Bonzini wrote:
On 07/02/2018 07:25, Wanpeng Li wrote:
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 786cd00..445e702 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7458,6 +7458,11 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu,
st
type, the
performance of guest accesses to those pages would be harmed.
Therefore, we check the host memory type in addition and only treat
UC/UC- pages as MMIO.
Reviewed-by: Xiao Guangrong
On 11/03/2017 05:29 PM, Haozhong Zhang wrote:
On 11/03/17 17:24 +0800, Xiao Guangrong wrote:
On 11/03/2017 05:02 PM, Haozhong Zhang wrote:
On 11/03/17 16:51 +0800, Haozhong Zhang wrote:
On 11/03/17 14:54 +0800, Xiao Guangrong wrote:
On 11/03/2017 01:53 PM, Haozhong Zhang wrote:
Some
On 11/03/2017 05:02 PM, Haozhong Zhang wrote:
On 11/03/17 16:51 +0800, Haozhong Zhang wrote:
On 11/03/17 14:54 +0800, Xiao Guangrong wrote:
On 11/03/2017 01:53 PM, Haozhong Zhang wrote:
Some reserved pages, such as those from NVDIMM DAX devices, are
not for MMIO, and can be mapped with
On 11/03/2017 04:51 PM, Haozhong Zhang wrote:
On 11/03/17 14:54 +0800, Xiao Guangrong wrote:
On 11/03/2017 01:53 PM, Haozhong Zhang wrote:
Some reserved pages, such as those from NVDIMM DAX devices, are
not for MMIO, and can be mapped with cached memory type for better
performance. However
On 11/03/2017 01:53 PM, Haozhong Zhang wrote:
Some reserved pages, such as those from NVDIMM DAX devices, are
not for MMIO, and can be mapped with cached memory type for better
performance. However, the above check misconceives those pages as
MMIO. Because KVM maps MMIO pages with UC memory ty
On 10/31/2017 07:48 PM, Haozhong Zhang wrote:
Some reserved pages, such as those from NVDIMM DAX devices, are
not for MMIO, and can be mapped with cached memory type for better
performance. However, the above check misconceives those pages as
MMIO. Because KVM maps MMIO pages with UC memory ty
On 10/27/2017 10:25 AM, Haozhong Zhang wrote:
[I just copy the commit message from patch 3]
By default, KVM treats a reserved page as for MMIO purpose, and maps
it to guest with UC memory type. However, some reserved pages are not
for MMIO, such as pages of DAX device (e.g., /dev/daxX.Y). Map
On 07/03/2017 11:47 PM, Paolo Bonzini wrote:
On 03/07/2017 16:39, Xiao Guangrong wrote:
On 06/20/2017 05:15 PM, guangrong.x...@gmail.com wrote:
From: Xiao Guangrong
Changelog in v2:
thanks to Paolo's review, this version disables write-protect-all if
PML is supported
Hi Paolo
On 06/20/2017 05:15 PM, guangrong.x...@gmail.com wrote:
From: Xiao Guangrong
Changelog in v2:
thanks to Paolo's review, this version disables write-protect-all if
PML is supported
Hi Paolo,
Do you have time to have a look at this new version? ;)
Or I should wait until the patchs
On 05/30/2017 12:48 AM, Paolo Bonzini wrote:
On 23/05/2017 04:23, Xiao Guangrong wrote:
Ping...
Sorry to disturb, just make this patchset not be missed. :)
It won't. :) I'm going to look at it and the dirty page ring buffer
this week.
Ping.. :)
On 06/05/2017 03:36 PM, Jay Zhou wrote:
/* enable ucontrol for s390 */
struct kvm_s390_ucas_mapping {
diff --git a/memory.c b/memory.c
index 4c95aaf..b836675 100644
--- a/memory.c
+++ b/memory.c
@@ -809,6 +809,13 @@ static void address_space_update_ioeventfds(AddressSpace
*as)
flatv
Ping...
Sorry to disturb, just make this patchset not be missed. :)
On 05/04/2017 03:06 PM, Paolo Bonzini wrote:
On 04/05/2017 05:36, Xiao Guangrong wrote:
Great.
As there is no conflict between these two patchsets except dirty
ring pages takes benefit from write-protect-all, i think they
CC Kevin as i am not sure if Intel is aware of this issue, it
breaks other hypervisors, e.g, Xen, as swell.
On 05/11/2017 07:23 PM, Paolo Bonzini wrote:
The new ept_access_test_paddr_read_only_ad_disabled testcase
caused an infinite stream of EPT violations because KVM did not
find anything bad
On 05/12/2017 11:59 AM, Xiao Guangrong wrote:
error:
@@ -452,7 +459,7 @@ static int FNAME(walk_addr_generic)(struct guest_walker
*walker,
*/
if (!(errcode & PFERR_RSVD_MASK)) {
vcpu->arch.exit_qualification &= 0x187;
-vcpu->arch.exit_qualification
((pt_access & pte) & 0x7) << 3;
^ here, the
original code
is buggy as pt_access and pte have different bit order, fortunately, this patch
fixes it
too. :)
Otherwise it looks good to me, thanks for your fix.
Reviewed-by: Xiao Guangrong
On 05/03/2017 10:57 PM, Paolo Bonzini wrote:
On 03/05/2017 16:50, Xiao Guangrong wrote:
Furthermore, userspace has no knowledge about if PML is enable (it
can be required from sysfs, but it is a good way in QEMU), so it is
difficult for the usespace to know when to use write-protect-all
On 05/03/2017 08:28 PM, Paolo Bonzini wrote:
So if I understand correctly this relies on userspace doing:
1) KVM_GET_DIRTY_LOG without write protect
2) KVM_WRITE_PROTECT_ALL_MEM
Writes may happen between 1 and 2; they are not represented in the live
dirty bitmap but i
On 04/12/2017 09:16 PM, Sironi, Filippo wrote:
Thanks for taking the time and sorry for the delay.
On 6. Apr 2017, at 16:22, Radim Krčmář wrote:
2017-04-05 15:07+0200, Filippo Sironi:
cmpxchg_gpte() calls get_user_pages_fast() to retrieve the number of
pages and the respective struct pages
On 31/03/2017 4:30 AM, Alan Tull wrote:
On Thu, Mar 30, 2017 at 7:08 AM, Wu Hao wrote:
From: Kang Luwei
Partial Reconfiguration (PR) is the most important function for FME. It
allows reconfiguration for given Port/Accelerated Function Unit (AFU).
This patch adds support for PR sub feature.
he init
function is called in kvm_arch_init_vm().
Otherwise it looks great to me:
Reviewed-by: Xiao Guangrong
Thanks for the fix.
On 09/14/2016 11:38 PM, Oleg Nesterov wrote:
On 09/13, Dave Hansen wrote:
On 09/13/2016 07:59 AM, Oleg Nesterov wrote:
I agree. I don't even understand why this was considered as a bug.
Obviously, m_stop() which drops mmap_sep should not be called, or
all the threads should be stopped, if yo
On 09/13/2016 03:10 AM, Michal Hocko wrote:
On Mon 12-09-16 08:01:06, Dave Hansen wrote:
On 09/12/2016 05:54 AM, Michal Hocko wrote:
In order to fix this bug, we make 'file->version' indicate the end address
of current VMA
Doesn't this open doors to another weird cases. Say B would be partia
On 09/12/2016 11:44 AM, Rudoff, Andy wrote:
Whether msync/fsync can make data persistent depends on ADR feature on
memory controller, if it exists everything works well, otherwise, we need
to have another interface that is why 'Flush hint table' in ACPI comes
in. 'Flush hint table' is particula
On 09/09/2016 11:40 PM, Dan Williams wrote:
On Fri, Sep 9, 2016 at 1:55 AM, Xiao Guangrong
wrote:
[..]
Whether a persistent memory mapping requires an msync/fsync is a
filesystem specific question. This mincore proposal is separate from
that. Consider device-DAX for volatile memory or
:
Thanks to Dave Hansen's comments, this version fixes the issue in v1 that
same virtual address range may be outputted twice, e.g:
Take two example VMAs:
vma-A: (0x1000 -> 0x2000)
vma-B: (0x2000 -> 0x3000)
read() #1: prints vma-A, sets m->version=0x2000
Now, merge A/B to
On 09/09/2016 07:04 AM, Dan Williams wrote:
On Thu, Sep 8, 2016 at 3:56 PM, Ross Zwisler
wrote:
On Wed, Sep 07, 2016 at 09:32:36PM -0700, Dan Williams wrote:
[ adding linux-fsdevel and linux-nvdimm ]
On Wed, Sep 7, 2016 at 8:36 PM, Xiao Guangrong
wrote:
[..]
However, it is not easy to
On 09/08/2016 10:05 PM, Dave Hansen wrote:
On 09/07/2016 08:36 PM, Xiao Guangrong wrote:>> The user will see two
VMAs in their output:
A: 0x1000->0x2000
C: 0x1000->0x3000
Will it confuse them to see the same virtual address range twice? Or is
there something pre
On 09/08/2016 12:34 AM, Dave Hansen wrote:
On 09/06/2016 11:51 PM, Xiao Guangrong wrote:
In order to fix this bug, we make 'file->version' indicate the next VMA
we want to handle
This new approach makes it more likely that we'll skip a new VMA that
gets inserted in between
Sorry, the title should be [PATCH] mm, proc: Fix region lost in /proc/self/smaps
On 09/07/2016 02:51 PM, Xiao Guangrong wrote:
Recently, Redhat reported that nvml test suite failed on QEMU/KVM,
more detailed info please refer to:
https://bugzilla.redhat.com/show_bug.cgi?id=1365721
Actually
unmap VMA B
issue read() again to continue to get
the region info
find_vma(version) will get VMA C
m_next_vma(C) will get VMA D
handle D
!!! VMA C is lost !!!
In order to fix this bug, we make 'file->version' indicate the next VMA
we want to handle
Signed-off-by
On 08/31/2016 01:09 AM, Dan Williams wrote:
Can you post your exact reproduction steps? This test is not failing for me.
Sure.
1. make the guest kernel based on your tree, the top commit is
10d7902fa0e82b (dax: unmap/truncate on device shutdown) and
the config file can be found in
On 08/30/2016 03:30 AM, Ross Zwisler wrote:
Can you please verify that you are using "usable" memory for your memmap? All
the details are here:
https://nvdimm.wiki.kernel.org/how_to_choose_the_correct_memmap_kernel_parameter_for_pmem_on_your_system
Sure.
This is the BIOS E820 info in the
Hi Ross,
Sorry for the delay, i just returned back from KVM Forum.
On 08/20/2016 02:30 AM, Ross Zwisler wrote:
On Fri, Aug 19, 2016 at 07:59:29AM -0700, Dan Williams wrote:
On Fri, Aug 19, 2016 at 4:19 AM, Xiao Guangrong
wrote:
Hi Dan,
Recently, Redhat reported that nvml test suite
On 07/06/2016 07:48 PM, Paolo Bonzini wrote:
On 06/07/2016 06:02, Xiao Guangrong wrote:
May I ask you what the exact issue you have with this interface for
Intel to support
your own GPU virtualization?
Intel's vGPU can work with this framework. We really appreciate your
/ nvi
On 07/06/2016 10:57 AM, Neo Jia wrote:
On Wed, Jul 06, 2016 at 10:35:18AM +0800, Xiao Guangrong wrote:
On 07/06/2016 10:18 AM, Neo Jia wrote:
On Wed, Jul 06, 2016 at 10:00:46AM +0800, Xiao Guangrong wrote:
On 07/05/2016 08:18 PM, Paolo Bonzini wrote:
On 05/07/2016 07:41, Neo Jia
On 07/06/2016 10:18 AM, Neo Jia wrote:
On Wed, Jul 06, 2016 at 10:00:46AM +0800, Xiao Guangrong wrote:
On 07/05/2016 08:18 PM, Paolo Bonzini wrote:
On 05/07/2016 07:41, Neo Jia wrote:
On Thu, Jun 30, 2016 at 03:01:49PM +0200, Paolo Bonzini wrote:
The vGPU folks would like to trap the
On 07/05/2016 11:07 PM, Neo Jia wrote:
On Tue, Jul 05, 2016 at 05:02:46PM +0800, Xiao Guangrong wrote:
It is physically contiguous but it is done during the runtime, physically
contiguous doesn't mean
static partition at boot time. And only during runtime, the proper HW resource
wi
On 07/05/2016 08:18 PM, Paolo Bonzini wrote:
On 05/07/2016 07:41, Neo Jia wrote:
On Thu, Jun 30, 2016 at 03:01:49PM +0200, Paolo Bonzini wrote:
The vGPU folks would like to trap the first access to a BAR by setting
vm_ops on the VMAs produced by mmap-ing a VFIO device. The fault handler
th
On 07/05/2016 03:30 PM, Neo Jia wrote:
(Just for completeness, if you really want to use a device in above example as
VFIO passthru, the second step is not completely handled in userspace, it is
actually the guest
driver who will allocate and setup the proper hw resource which will later re
On 07/05/2016 01:16 PM, Neo Jia wrote:
On Tue, Jul 05, 2016 at 12:02:42PM +0800, Xiao Guangrong wrote:
On 07/05/2016 09:35 AM, Neo Jia wrote:
On Tue, Jul 05, 2016 at 09:19:40AM +0800, Xiao Guangrong wrote:
On 07/04/2016 11:33 PM, Neo Jia wrote:
Sorry, I think I misread the
On 07/05/2016 09:35 AM, Neo Jia wrote:
On Tue, Jul 05, 2016 at 09:19:40AM +0800, Xiao Guangrong wrote:
On 07/04/2016 11:33 PM, Neo Jia wrote:
Sorry, I think I misread the "allocation" as "mapping". We only delay the
cpu mapping, not the allocation.
So how to under
On 07/04/2016 11:33 PM, Neo Jia wrote:
Sorry, I think I misread the "allocation" as "mapping". We only delay the
cpu mapping, not the allocation.
So how to understand your statement:
"at that moment nobody has any knowledge about how the physical mmio gets
virtualized"
The resource, physi
On 07/04/2016 05:16 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 04:45:05PM +0800, Xiao Guangrong wrote:
On 07/04/2016 04:41 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 04:19:20PM +0800, Xiao Guangrong wrote:
On 07/04/2016 03:53 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 03:37:35PM +0800
On 07/04/2016 04:45 PM, Xiao Guangrong wrote:
On 07/04/2016 04:41 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 04:19:20PM +0800, Xiao Guangrong wrote:
On 07/04/2016 03:53 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 03:37:35PM +0800, Xiao Guangrong wrote:
On 07/04/2016 03:03 PM, Neo Jia
On 07/04/2016 04:41 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 04:19:20PM +0800, Xiao Guangrong wrote:
On 07/04/2016 03:53 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 03:37:35PM +0800, Xiao Guangrong wrote:
On 07/04/2016 03:03 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 02:39:22PM +0800
On 07/04/2016 04:14 PM, Paolo Bonzini wrote:
On 04/07/2016 09:59, Xiao Guangrong wrote:
But apart from this, it's much more obvious to consider the refcount.
The x86 MMU code doesn't care if the page is reserved or not;
mmu_set_spte does a kvm_release_pfn_clean, hence it makes
On 07/04/2016 03:53 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 03:37:35PM +0800, Xiao Guangrong wrote:
On 07/04/2016 03:03 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 02:39:22PM +0800, Xiao Guangrong wrote:
On 06/30/2016 09:01 PM, Paolo Bonzini wrote:
The vGPU folks would like to trap
On 07/04/2016 03:48 PM, Paolo Bonzini wrote:
On 04/07/2016 09:37, Xiao Guangrong wrote:
It actually is a portion of the physical mmio which is set by vfio mmap.
So i do not think we need to care its refcount, i,e, we can consider it
as reserved_pfn,
Paolo?
nVidia provided me (offlist
On 07/04/2016 03:38 PM, Paolo Bonzini wrote:
On 04/07/2016 08:39, Xiao Guangrong wrote:
Why the memory mapped by this mmap() is not a portion of MMIO from
underlayer physical device? If it is a valid system memory, is this
interface
really needed to implemented in vfio? (you at least need
On 07/04/2016 03:03 PM, Neo Jia wrote:
On Mon, Jul 04, 2016 at 02:39:22PM +0800, Xiao Guangrong wrote:
On 06/30/2016 09:01 PM, Paolo Bonzini wrote:
The vGPU folks would like to trap the first access to a BAR by setting
vm_ops on the VMAs produced by mmap-ing a VFIO device. The fault
On 06/30/2016 09:01 PM, Paolo Bonzini wrote:
The vGPU folks would like to trap the first access to a BAR by setting
vm_ops on the VMAs produced by mmap-ing a VFIO device. The fault handler
then can use remap_pfn_range to place some non-reserved pages in the VMA.
Why does it require fetching
On 06/29/2016 04:18 PM, Paolo Bonzini wrote:
On 29/06/2016 05:17, Xiao Guangrong wrote:
+++ b/arch/x86/kvm/mmu.c
@@ -2516,13 +2516,17 @@ static int set_spte(struct kvm_vcpu *vcpu, u64
*sptep,
gfn_t gfn, kvm_pfn_t pfn, bool speculative,
bool can_unsync, bool
On 06/28/2016 12:32 PM, Bandan Das wrote:
To support execute only mappings on behalf of L1
hypervisors, we teach set_spte() to honor L1's valid XWR
bits. This is only if host supports EPT execute only. Reuse
ACC_USER_MASK to signify if the L1 hypervisor has the R bit
set
Signed-off-by: Bandan
On 06/28/2016 12:32 PM, Bandan Das wrote:
In reset_tdp_shadow_zero_bits_mask, we always pass false
when initializing the reserved bits. By initializing with the
correct value of ept exec only, the host can correctly
identify if the guest pte is valid. Note that
kvm_init_shadow_ept_mmu() already
On 06/29/2016 04:49 AM, Paolo Bonzini wrote:
On 28/06/2016 22:37, Bandan Das wrote:
Paolo Bonzini writes:
On 28/06/2016 19:33, Bandan Das wrote:
static int is_shadow_present_pte(u64 pte)
{
- return pte & PT_PRESENT_MASK && !is_mmio_spte(pte);
+ return pte & (PT_PRESENT_MA
On 04/06/2016 04:56 PM, Paolo Bonzini wrote:
On 25/03/2016 14:19, Xiao Guangrong wrote:
@@ -193,11 +193,11 @@ static inline u8 permission_fault(struct kvm_vcpu *vcpu,
struct kvm_mmu *mmu,
((pte_access & PT_USER_MASK) << (PFERR_RSVD_BIT -
PT_USER_SHIFT));
On 03/30/2016 02:39 PM, Xiao Guangrong wrote:
On 03/30/2016 02:36 PM, Paolo Bonzini wrote:
On 30/03/2016 03:56, Xiao Guangrong wrote:
x86/access.flat is currently using the "other" definition, i.e., PFEC.PK
is only set if W=1 or CR0.WP=0 && PFEC.U=0 or PFEC.W=0. Can yo
On 03/30/2016 02:36 PM, Paolo Bonzini wrote:
On 30/03/2016 03:56, Xiao Guangrong wrote:
x86/access.flat is currently using the "other" definition, i.e., PFEC.PK
is only set if W=1 or CR0.WP=0 && PFEC.U=0 or PFEC.W=0. Can you use it
(with ept=1 of course) to check wha
On 03/30/2016 04:09 AM, Paolo Bonzini wrote:
On 29/03/2016 19:43, Xiao Guangrong wrote:
Based on the SDM:
PK flag (bit 5).
This flag is 1 if (1) IA32_EFER.LMA = CR4.PKE = 1; (2) the access
causing the page-fault exception was a data access; (3) the linear
address was a user-mode address
On 03/25/2016 10:21 PM, Paolo Bonzini wrote:
On 25/03/2016 14:19, Xiao Guangrong wrote:
WARN_ON(pfec & (PFERR_PK_MASK | PFERR_RSVD_MASK));
- pfec |= PFERR_PRESENT_MASK;
+ errcode = PFERR_PRESENT_MASK;
if (unlikely(mmu->pkru_mask)) {
u32 pk
On 03/25/2016 09:56 PM, Paolo Bonzini wrote:
On 25/03/2016 14:48, Xiao Guangrong wrote:
This patch and the previous one are basically redoing commit
0a47cd85833e ("KVM: MMU: Fix ubsan warnings", 2016-03-04). While you
find your version easier to understand, I of course find m
On 03/25/2016 09:45 PM, Paolo Bonzini wrote:
On 25/03/2016 14:19, Xiao Guangrong wrote:
Currently only PT64_ROOT_LEVEL - 1 levels are used, one additional entry
in .parent[] is used as a sentinel, the additional entry in .idx[] is
purely wasted
This patch reduces its size and sets the
On 03/25/2016 09:35 PM, Paolo Bonzini wrote:
On 25/03/2016 14:19, Xiao Guangrong wrote:
kvm-unit-tests complained about the PFEC is not set properly, e.g,:
test pte.rw pte.d pte.nx pde.p pde.rw pde.pse user fetch: FAIL: error code 15
expected 5
Dump mapping: address: 0x1234
--L4
Currently only PT64_ROOT_LEVEL - 1 levels are used, one additional entry
in .parent[] is used as a sentinel, the additional entry in .idx[] is
purely wasted
This patch reduces its size and sets the sentinel on the upper level of
the place where we start from
Signed-off-by: Xiao Guangrong
patch simplifies it by saving the sp and its index to kvm_mmu_pages,
then it is much easier to understand the operations on the its index
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/mmu.c | 40 ++--
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git
ed to guest is copied from the
PFEC triggered by shadow page table
This patch fixes it and makes the logic of updating errcode more clean
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/mmu.h | 8
arch/x86/kvm/paging_tmpl.h | 2 +-
2 files changed, 5 insertions(+), 5 dele
ff-by: Xiao Guangrong
---
arch/x86/kvm/mmu.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c396e8b..4d66a9e 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1906,18 +1906,17 @@ static
[kvm]
[ 132.179372] [] handle_exception+0x1b2/0x430 [kvm_intel]
[ 132.187072] [] vmx_handle_exit+0x1e1/0xc50 [kvm_intel]
...
Thank you for fixing it, Paolo!
Reviewed-by: Xiao Guangrong
On 03/16/2016 03:32 AM, Paolo Bonzini wrote:
On 15/03/2016 19:27, Andy Lutomirski wrote:
On Mon, Mar 14, 2016 at 6:17 AM, Paolo Bonzini wrote:
On 11/03/2016 22:33, David Matlack wrote:
Is this better than just always keeping the host's XCR0 loaded outside
if the KVM interrupts-disabled
On 03/16/2016 03:01 AM, David Matlack wrote:
On Mon, Mar 14, 2016 at 12:46 AM, Xiao Guangrong
wrote:
On 03/12/2016 04:47 AM, David Matlack wrote:
I have not been able to trigger this bug on Linux 4.3, and suspect
it is due to this commit from Linux 4.2:
653f52c kvm,x86: load guest FPU
On 03/12/2016 04:47 AM, David Matlack wrote:
I have not been able to trigger this bug on Linux 4.3, and suspect
it is due to this commit from Linux 4.2:
653f52c kvm,x86: load guest FPU context more eagerly
With this commit, as long as the host is using eagerfpu, the guest's
fpu is always loa
On 03/11/2016 01:07 AM, Paolo Bonzini wrote:
On 09/03/2016 08:18, Lan Tianyu wrote:
How about the following comments.
Log for kvm_mmu_commit_zap_page()
/*
* We need to make sure everyone sees our modifications to
* the page tables and see changes to vcpu->mode here.
On 03/11/2016 12:04 AM, Paolo Bonzini wrote:
On 10/03/2016 16:45, Xiao Guangrong wrote:
Compared to smp_load_acquire(), smp_mb() adds an ordering between stores
and loads.
Here, the ordering is load-store, hence...
Yes, this is why i put smp_mb() in the code. :)
Here is a table of
On 03/10/2016 11:31 PM, Paolo Bonzini wrote:
On 10/03/2016 16:26, Paolo Bonzini wrote:
Compared to smp_load_acquire(), smp_mb() adds an ordering between stores
and loads.
Here, the ordering is load-store, hence...
Yes, this is why i put smp_mb() in the code. :)
Signed-off-by: Xiao Guangrong
Signed-off-by: Marcelo Tosatti
Unfortunately that patch added a bad memory barrier: 1) it lacks a
comment; 2) it lacks obvious pairing; 3) it is an smp_mb() after a read,
so it's not even obvious that this memory barrier has to do with the
immediatel
Right now it only adds the P bit to the input parameter "pfec", but PKU
can change that.
Yep, i got the same idea when i reviewed the pkey patchset. This patch
looks good to me.
Reviewed-by: Xiao Guangrong
On 03/08/2016 07:45 PM, Paolo Bonzini wrote:
For the next patch, we will want to filter PFERR_FETCH_MASK away early,
and not pass it to permission_fault if neither NX nor SMEP are enabled.
Prepare for the change.
Why it is needed? It is much easier to drop PFEC.F in
update_permission_bitmask(
On 03/08/2016 07:44 PM, Paolo Bonzini wrote:
Patch 1 ensures that all aspects of MPX are disabled when eager FPU
is disabled on the host. Patch 2 is just a cleanup.
It looks good to me.
Reviewed-by: Xiao Guangrong
Now, more and more features depend on eger xsave, e.g, fpu, mpx and
On 03/10/2016 06:09 PM, Paolo Bonzini wrote:
On 10/03/2016 09:27, Xiao Guangrong wrote:
+if (!enable_ept) {
+guest_efer |= EFER_NX;
+ignore_bits |= EFER_NX;
Update ignore_bits is not necessary i think.
More precisely, ignore_bits is only needed if guest EFER.NX=0
On 03/08/2016 07:44 PM, Paolo Bonzini wrote:
Yes, all of these are needed. :) This is admittedly a bit odd, but
kvm-unit-tests access.flat tests this if you run it with "-cpu host"
and of course ept=0.
KVM handles supervisor writes of a pte.u=0/pte.w=0/CR0.WP=0 page by
setting U=0 and W=1 in t
it only looks at the guest's EFER.NX bit. Teach it
that smep_andnot_wp will also use the NX bit of SPTEs.
Cc: sta...@vger.kernel.org
Cc: Xiao Guangrong
As a redhat guy i am so proud. :)
Fixes: c258b62b264fdc469b6d3610a907708068145e3b
Thanks for you fixing it, Paolo!
Reviewed-by:
t to a
separate patch for easier application to stable kernels.
Cc: sta...@vger.kernel.org
Cc: Xiao Guangrong
Cc: Andy Lutomirski
Fixes: f6577a5fa15d82217ca73c74cd2dcbc0f6c781dd
Signed-off-by: Paolo Bonzini
---
Documentation/virtual/kvm/mmu.txt | 3 ++-
arch/x86/kvm/vmx.c
even simpler way.
Nice work!
Reviewed-by: Xiao Guangrong
On 03/04/2016 04:04 PM, Paolo Bonzini wrote:
On 04/03/2016 02:35, Lan Tianyu wrote:
The following kvm_flush_remote_tlbs() will call smp_mb() inside and so
remove smp_mb() here.
Signed-off-by: Lan Tianyu
---
arch/x86/kvm/mmu.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/x
ic void vmx_set_dr7(struct kvm_vcpu *vcpu, unsigned long val)
Reviewed-by: Xiao Guangrong
On 02/26/2016 07:46 PM, Paolo Bonzini wrote:
Commit 172b2386ed16 ("KVM: x86: fix missed hardware breakpoints",
2016-02-10) worked around a case where the debug registers are not loaded
correctly on preemption and on the first entry to KVM_RUN.
However, Xiao Guangrong pointed out tha
On 02/26/2016 07:28 PM, Nadav Amit wrote:
Xiao Guangrong wrote:
On 02/19/2016 06:56 PM, Paolo Bonzini wrote:
Sometimes when setting a breakpoint a process doesn't stop on it.
This is because the debug registers are not loaded correctly on
VCPU load.
diff --git a/arch/x86/kvm/x86.c b
On 02/19/2016 06:56 PM, Paolo Bonzini wrote:
Sometimes when setting a breakpoint a process doesn't stop on it.
This is because the debug registers are not loaded correctly on
VCPU load.
The following simple reproducer from Oleg Nesterov tries using debug
registers in two threads. To see the b
On 02/25/2016 04:49 PM, Paolo Bonzini wrote:
On 25/02/2016 08:35, Xiao Guangrong wrote:
This may release the mmu_lock before committing the zapping.
Is it safe? If so, we may want to see the reason in the changelog.
It is unsafe indeed, please do not do it.
Can you explain why
0x96/0x2b0
[ 168.792773] [] SyS_ioctl+0x79/0x90
[ 168.792777] [] entry_SYSCALL_64_fastpath+0x23/0xc1
[ 168.792780]
Signed-off-by: Mike Krinkin
Reviewed-by: Xiao Guangrong
On 02/24/2016 09:17 PM, Paolo Bonzini wrote:
This series started from looking at mmu_unsync_walk for the ubsan thread.
Patches 1 and 2 are the result of the discussions in that thread.
Patches 3 to 9 do more cleanups in __kvm_sync_page and its callers.
Among other changes, it removes kvm_sync_
On 02/25/2016 10:15 AM, Takuya Yoshikawa wrote:
On 2016/02/24 22:17, Paolo Bonzini wrote:
Move the call to kvm_mmu_flush_or_zap outside the loop.
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm
On 02/24/2016 09:17 PM, Paolo Bonzini wrote:
kvm_mmu_get_page is the only caller of kvm_sync_page_transient
and kvm_sync_pages. Moving the handling of the invalid_list there
removes the need for the underdocumented kvm_sync_page_transient
function.
Signed-off-by: Paolo Bonzini
---
Gu
1 - 100 of 1077 matches
Mail list logo
