This table summarizes the information of fixed MTRRs and introduce some APIs
to abstract its operation which helps us to clean up the code and will be
used in later patches
Signed-off-by: Xiao Guangrong guangrong.x...@linux.intel.com
---
arch/x86/kvm/mtrr.c | 200
Sort all valid variable MTRRs based on its base address, it will help us to
check a range to see if it's fully contained in variable MTRRs
Signed-off-by: Xiao Guangrong guangrong.x...@linux.intel.com
---
arch/x86/include/asm/kvm_host.h | 3 ++
arch/x86/kvm/mtrr.c | 63
Two functions are introduced:
- fixed_mtrr_addr_to_seg() translates the address to the fixed
MTRR segment
- fixed_mtrr_addr_seg_to_range_index() translates the address to
the index of kvm_mtrr.fixed_ranges[]
They will be used in the later patch
Signed-off-by: Xiao Guangrong
Variable MTRR MSRs are 64 bits which are directly accessed with full length,
no reason to split them to two 32 bits
Signed-off-by: Xiao Guangrong guangrong.x...@linux.intel.com
---
arch/x86/include/asm/kvm_host.h | 7 ++-
arch/x86/kvm/mtrr.c | 32 ++--
It walks all MTRRs and gets all the memory cache type setting for the
specified range also it checks if the range is fully covered by MTRRs
Signed-off-by: Xiao Guangrong guangrong.x...@linux.intel.com
---
arch/x86/kvm/mtrr.c | 188
1 file
It gets the range for the specified variable MTRR
Signed-off-by: Xiao Guangrong guangrong.x...@linux.intel.com
---
arch/x86/kvm/mtrr.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index df73149..cb9702d 100644
vMTRR does not depend on any host MTRR feature and fixed MTRRs have always
been implemented, so drop this field
Signed-off-by: Xiao Guangrong guangrong.x...@linux.intel.com
---
arch/x86/include/asm/kvm_host.h | 9 -
arch/x86/kvm/mtrr.c | 7 +++
arch/x86/kvm/x86.c
MSR_MTRRcap is a MTRR msr so move the handler to the common place, also
add some comments to make the hard code more readable
Signed-off-by: Xiao Guangrong guangrong.x...@linux.intel.com
---
arch/x86/kvm/mtrr.c | 12
arch/x86/kvm/x86.c | 2 --
2 files changed, 12 insertions(+), 2
Only KVM_NR_VAR_MTRR variable MTRRs are available in KVM guest
Signed-off-by: Xiao Guangrong guangrong.x...@linux.intel.com
---
arch/x86/include/asm/kvm_host.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
MTRR code locates in x86.c and mmu.c so that move them to a separate file to
make the organization more clearer and it will be the place where we fully
implement vMTRR
Signed-off-by: Xiao Guangrong guangrong.x...@linux.intel.com
---
arch/x86/include/asm/kvm_host.h | 1 -
arch/x86/kvm/Makefile
Currently, CR0.CD is not checked when we virtualize memory cache type for
noncoherent_dma guests, this patch fixes it by :
- setting UC for all memory if CR0.CD = 1
- zapping all the last sptes in MMU if CR0.CD is changed
Signed-off-by: Xiao Guangrong guangrong.x...@linux.intel.com
---
On Fri, Jun 12, 2015 at 04:57:42PM -0500, Timur Tabi wrote:
From: Shanker Donthineni shank...@codeaurora.org
This patch adds define for Qualcomm Technologies ARMv8 CPU
implementer ID 0x51 and part number for Kryo in asm/cputype.h.
Signed-off-by: Shanker Donthineni shank...@codeaurora.org
W/o dedicated endianess it's impossible to find reliably a match
e.g. in kernel/virt/kvm/eventfd.c ioeventfd_in_range.
Signed-off-by: Andreas Herrmann andreas.herrm...@caviumnetworks.com
---
ioeventfd.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/ioeventfd.c
VIRTIO_PCI_QUEUE_NOTIFY is 16-bit and iowrite16 is used in
drivers/virtio/virtio_pci.c to notify the other side.
If the size doesn't match notification via mmio write will fail.
Signed-off-by: Andreas Herrmann andreas.herrm...@caviumnetworks.com
---
virtio/pci.c |2 +-
1 file changed, 1
When including asm-generic/types.h instead of asm/types.h it results
in conflicting types for __s64 et al (at least with my
toolchain). Other header files are including asm/types.h
(e.g. include/kvm/ioport.h) and types defined there don't necessarily
match the types defined in asm-generic/types.h.
Hi Will,
Following some patches to fix misc issues found when testing the
standalone kvmtool version.
Please apply.
Thanks,
Andreas
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Since commit d2a7ddff4 (Add minimal support for macvtap) opening
of tap device might fail. lkvm shows
Warning: Config tap device error. Are you root?
virtio_net_request_tap passed wrong pointer for struct ifreq to
TUNSETIFF ioctl.
Signed-off-by: Andreas Herrmann
Hi Mario,
I was working on a more ambitious patch series, but we probably ought to
start small, and this looks fairly sensible to me.
A few minor comments below.
On 13/06/15 23:20, Mario Smarduch wrote:
Currently VFP/SIMD registers are always saved and restored
on Guest entry and exit.
On 06/05/2015 05:41 PM, Will Deacon wrote:
On Thu, Jun 04, 2015 at 04:20:45PM +0100, Andre Przywara wrote:
Hi Will,
sorry, almost forgot about this email...
In PCI config space there is an interrupt line field (offset 0x3f),
which is used to initially communicate the IRQ line number from
Hi Marc,
On 06/10/2015 06:21 PM, Marc Zyngier wrote:
On 05/06/15 09:37, Andre Przywara wrote:
Extend the vGIC handling code to potentially deal with different IRQ
chip devices instead of hard-coding the GICv2 in.
We extend most vGIC functions to take a type parameter, but still put
GICv2 in
On 15/06/15 12:12, Andre Przywara wrote:
On 06/10/2015 06:40 PM, Marc Zyngier wrote:
On 05/06/15 09:37, Andre Przywara wrote:
The code currently is assuming fixed sized memory regions for the
distributor and CPU interface. GICv3 needs a dynamic allocation of
its redistributor region, since
- kvm_mtrr_get_guest_memory_type() only checks one page in MTRRs so
that it's unnecessary to check to see if the range is partially
covered in MTRR
- optimize the check of overlap memory type and add some comments
to explain the precedence
Signed-off-by: Xiao Guangrong
Drop kvm_mtrr-enable, omit the decode/code workload and get rid of
all the hard code
Signed-off-by: Xiao Guangrong guangrong.x...@linux.intel.com
---
arch/x86/include/asm/kvm_host.h | 3 +--
arch/x86/kvm/mtrr.c | 40
2 files changed, 29
mtrr_for_each_mem_type() is ready now, use it to simplify
kvm_mtrr_get_guest_memory_type()
Signed-off-by: Xiao Guangrong guangrong.x...@linux.intel.com
---
arch/x86/kvm/mtrr.c | 64 ++---
1 file changed, 16 insertions(+), 48 deletions(-)
diff
Changlog:
- let's fix the bugs for noncoherent_dma guests first
- these changes are from Paolo's review
1) use inline functions instead of union definition for 'struct kvm_mtrr'
2) improve code style
3) fix fixed_msr_to_range_index which does not return the actual value
4) introduce
Based on Intel's SDM, mapping huge page which do not have consistent
memory cache for each 4k page will cause undefined behavior
In order to avoiding this kind of undefined behavior, we force to use
4k pages under this case
Signed-off-by: Xiao Guangrong guangrong.x...@linux.intel.com
---
On 06/10/2015 06:40 PM, Marc Zyngier wrote:
On 05/06/15 09:37, Andre Przywara wrote:
The code currently is assuming fixed sized memory regions for the
distributor and CPU interface. GICv3 needs a dynamic allocation of
its redistributor region, since its size depends on the number of
vCPUs.
Otherwise vhost does not work if a virtio descriptor is used that was
allocated from a guest memory bank not registered as
vhost_memory_region.
Signed-off-by: Andreas Herrmann andreas.herrm...@caviumnetworks.com
---
virtio/net.c | 21 +
1 file changed, 13 insertions(+), 8
Hi Peter,
thank you for comments. See answers below.
On Fri, 2015-06-12 at 16:03 -0700, Peter Hornyack wrote:
Hi Denis, Andrey, I have a few comments and questions. (re-sending in
plain-text mode, apologies for sending twice.)
On Thu, Jun 11, 2015 at 6:18 AM, Denis V. Lunev d...@openvz.org
Hi Marc,
On 06/08/2015 07:04 PM, Marc Zyngier wrote:
In order to be able to feed physical interrupts to a guest, we need
to be able to establish the virtual-physical mapping between the two
worlds.
The mapping is kept in a rbtree, indexed by virtual interrupts.
Signed-off-by: Marc Zyngier
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Saturday, June 13, 2015 3:04 AM
To: Avi Kivity
Cc: Wu, Feng; kvm@vger.kernel.org; linux-ker...@vger.kernel.org;
pbonz...@redhat.com; mtosa...@redhat.com; eric.au...@linaro.org
Subject: Re: [v4
perf kvm {record|report} is used to record and report the performance
profile of any workload on a guest. From the host, we can collect
guest kernel statistics which is useful in finding out any contentions
in guest kernel symbols for a certain workload.
This feature is not available on powerpc
In order to enable userspace PIC support, the userspace PIC needs to
be able to inject local interrupt requests.
This adds the ioctl KVM_REQUEST_PIC_INJECTION and kvm exit
KVM_EXIT_GET_EXTINT.
The vm ioctl KVM_REQUEST_PIC_INJECTION makes a KVM_REQ_EVENT request
on the BSP, which causes the BSP
Adds KVM_EXIT_IOAPIC_EOI which allows the kernel to EOI
level-triggered IOAPIC interrupts.
Uses a per VCPU exit bitmap to decide whether or not the IOAPIC needs
to be informed (which is identical to the EOI_EXIT_BITMAP field used
by modern x86 processors, but can also be used to elide kvm IOAPIC
First patch in a series which enables the relocation of the
PIC/IOAPIC to userspace.
Adds capability KVM_CAP_SPLIT_IRQCHIP;
KVM_CAP_SPLIT_IRQCHIP enables the construction of LAPICs without the
rest of the irqchip.
Compile tested for x86.
Signed-off-by: Steve Rutherford srutherf...@google.com
In order to support a userspace IOAPIC interacting with an in kernel
APIC, the EOI exit bitmaps need to be configurable.
If the IOAPIC is in userspace (i.e. the irqchip has been split), the
EOI exit bitmaps will be set whenever the GSI Routes are configured.
In particular, for the low MSI routes
On 06/15/2015 11:20 AM, Marc Zyngier wrote:
On 15/06/15 19:04, Mario Smarduch wrote:
On 06/15/2015 03:00 AM, Marc Zyngier wrote:
Hi Mario,
[ ... ]
On 13/06/15 23:20, Mario Smarduch wrote:
Currently VFP/SIMD registers are always saved and restored
on Guest entry and exit.
This patch only
This is an incremental update to the userfaultfd code in -mm.
This fixes two bugs that could cause some malfunction (but nothing
that could cause memory corruption or kernel crashes of any sort,
neither in kernel nor userland).
This also introduces some enhancement: gdb now runs fine, signals
This is only simple to achieve if the userfault is going to return to
userland (not to the kernel) because we can avoid returning
VM_FAULT_RETRY despite we temporarily released the mmap_sem. The fault
would just be retried by userland then. This is safe at least on x86
and powerpc (the two archs
On 15/06/15 19:44, Mario Smarduch wrote:
On 06/15/2015 11:20 AM, Marc Zyngier wrote:
On 15/06/15 19:04, Mario Smarduch wrote:
On 06/15/2015 03:00 AM, Marc Zyngier wrote:
Hi Mario,
I was working on a more ambitious patch series,
but we probably ought to
start small, and this looks fairly
On 06/15/2015 11:51 AM, Marc Zyngier wrote:
On 15/06/15 19:44, Mario Smarduch wrote:
On 06/15/2015 11:20 AM, Marc Zyngier wrote:
On 15/06/15 19:04, Mario Smarduch wrote:
On 06/15/2015 03:00 AM, Marc Zyngier wrote:
Hi Mario,
[...]
The 32bit code is starting to show its age, and could
On 06/15/2015 11:20 AM, Marc Zyngier wrote:
On 15/06/15 19:04, Mario Smarduch wrote:
On 06/15/2015 03:00 AM, Marc Zyngier wrote:
Hi Mario,
I was working on a more ambitious patch series,
but we probably ought to
start small, and this looks fairly sensible to me.
Hi Marc,
thanks for
On 06/15/2015 03:00 AM, Marc Zyngier wrote:
Hi Mario,
I was working on a more ambitious patch series,
but we probably ought to
start small, and this looks fairly sensible to me.
Hi Marc,
thanks for reviewing, I was thinking to post this
first and next iteration on guest access switch
On 15/06/15 19:04, Mario Smarduch wrote:
On 06/15/2015 03:00 AM, Marc Zyngier wrote:
Hi Mario,
I was working on a more ambitious patch series,
but we probably ought to
start small, and this looks fairly sensible to me.
Hi Marc,
thanks for reviewing, I was thinking to post this
first
This reverts commit 855c5a9026b0fce58c8de5382ef8ce00f74c1331 and
adapts fs/userfaultfd.c to use the old version of that function.
It didn't look robust to call __wake_up_common with nr == 1 when we
absolutely require wakeall semantics, but we've full control of what
we insert in the two waitqueue
On 06/11/2015 12:02 PM, Marc Zyngier wrote:
On 11/06/15 10:44, Andre Przywara wrote:
On 06/11/2015 10:15 AM, Marc Zyngier wrote:
On 11/06/15 09:44, Andre Przywara wrote:
On 06/08/2015 06:04 PM, Marc Zyngier wrote:
...
@@ -1344,6 +1364,35 @@ static bool vgic_process_maintenance(struct
Hi Alex, all,
On 06/12/2015 09:03 PM, Alex Williamson wrote:
On Fri, 2015-06-12 at 21:48 +0300, Avi Kivity wrote:
On 06/12/2015 06:41 PM, Alex Williamson wrote:
On Fri, 2015-06-12 at 00:23 +, Wu, Feng wrote:
-Original Message-
From: Avi Kivity [mailto:avi.kiv...@gmail.com]
Sent:
The THP faults were not propagating the original fault address. The latest
version of the API with uffd.arg.pagefault.address is supposed to propagate the
full address through THP faults.
This was not a kernel crashing bug and it wouldn't risk to corrupt
user memory, but it would cause a SIGBUS
This test allocates two virtual areas and bounces the physical memory
across the two virtual areas using only userfaultfd.
This exposed a race condition in the refile of the userfault in
userfaultfd_read and an alignment issue with the address returned to
userland with THP enabled. It also
During the refile in userfaultfd_read both waitqueues could look empty
to the lockless wake_userfault(). Use a seqcount to prevent this false
negative that could leave an userfault blocked.
Signed-off-by: Andrea Arcangeli aarca...@redhat.com
---
fs/userfaultfd.c | 26 --
Blocking reads can easily use exclusive wakeups. Poll in theory could
too but there's no poll_wait_exclusive in common code yet.
If a poll() non-exclusive waitqueue is encountered before the
exclusive readblocking waitqueue, then everything will be waken. If a
read exclusive waitqueue is
UFFDIO_API was already forced before read/poll could work. This
makes the code more strict to force it also for all other ioctls.
All users would already have been required to call UFFDIO_API before
invoking other ioctls but this makes it more explicit.
This will ensure we can change all ioctls
On Mon, 2015-06-15 at 18:17 +0200, Eric Auger wrote:
Hi Alex, all,
On 06/12/2015 09:03 PM, Alex Williamson wrote:
On Fri, 2015-06-12 at 21:48 +0300, Avi Kivity wrote:
On 06/12/2015 06:41 PM, Alex Williamson wrote:
On Fri, 2015-06-12 at 00:23 +, Wu, Feng wrote:
-Original
On Mon, Jun 15, 2015 at 08:11:50AM -1000, Linus Torvalds wrote:
On Jun 15, 2015 7:22 AM, Andrea Arcangeli aarca...@redhat.com wrote:
+ if (cmd != UFFDIO_API) {
+ if (ctx-state == UFFD_STATE_WAIT_API)
+ return -EINVAL;
+
On Mon, Jun 15, 2015 at 08:19:07AM -1000, Linus Torvalds wrote:
What if the process doing the polling never doors anything with the end
result? Maybe it meant to, but it got killed before it could? Are you going
to leave everybody else blocked, even though there are pending events?
Yes, it
55 matches
Mail list logo
