- 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
---
arch/x86/k
Drop kvm_mtrr->enable, omit the decode/code workload and get rid of
all the hard code
Signed-off-by: Xiao Guangrong
---
arch/x86/include/asm/kvm_host.h | 3 +--
arch/x86/kvm/mtrr.c | 40
2 files changed, 29 insertions(+), 14 deletions(-)
dif
mtrr_for_each_mem_type() is ready now, use it to simplify
kvm_mtrr_get_guest_memory_type()
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/mtrr.c | 64 ++---
1 file changed, 16 insertions(+), 48 deletions(-)
diff --git a/arch/x86/kvm/mtrr.c b/arch/
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 kvm_se
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
---
arch/x86/kvm/mmu.c | 20
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
---
arch/x86/include/asm/kvm_host.h | 7 ++-
arch/x86/kvm/mtrr.c | 32 ++--
2 files changed, 16 insertion
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
---
arch/x86/kvm/mtrr.c | 188
1 file changed, 188 insertions(+)
diff --
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
---
arch/x86/kvm/mtrr.c | 200 ++--
1 file ch
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
---
arch/x86/include/asm/kvm_host.h | 3 ++
arch/x86/kvm/mtrr.c | 63 ++---
ar
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
---
arch/x86/kv
It gets the range for the specified variable MTRR
Signed-off-by: Xiao Guangrong
---
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
--- a/arch/x86/kvm/mtrr.c
+++ b
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
---
arch/x86/include/asm/kvm_host.h | 9 -
arch/x86/kvm/mtrr.c | 7 +++
arch/x86/kvm/x86.c | 1 -
3 files changed, 11
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
---
arch/x86/kvm/mtrr.c | 12
arch/x86/kvm/x86.c | 2 --
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch
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
---
arch/x86/kvm/vmx.c | 32 +++
Only KVM_NR_VAR_MTRR variable MTRRs are available in KVM guest
Signed-off-by: Xiao Guangrong
---
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
index cbf9f07..fe9cbe4 100644
---
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
---
arch/x86/include/asm/kvm_host.h | 1 -
arch/x86/kvm/Makefile | 2 +-
arch/x86/kv
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.
>
>
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 wrote:
> > Fro
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
>> G
On Fri, Jun 12, 2015 at 04:57:42PM -0500, Timur Tabi wrote:
> From: Shanker Donthineni
>
> 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
> Signed-off-by: Timur Tabi
I think this
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
>> v
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 regio
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
---
virtio/net.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/virtio/net
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
---
virtio/pci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
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 http://vger.kernel
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
---
virtio/net.c |2 +-
1
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
---
ioeventfd.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/ioeventfd.c b/ioeventfd.c
index bce6861..a724baa 1006
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 Z
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_maintenanc
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...@gma
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:
> > -Or
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 can
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 wi
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 waitqueu
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 (
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 fa
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 allowed
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
---
fs/userfaultfd.c | 26 --
1 file changed, 24 i
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 encounter
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 switc
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 pos
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 M
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
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
On Mon, Jun 15, 2015 at 08:11:50AM -1000, Linus Torvalds wrote:
> On Jun 15, 2015 7:22 AM, "Andrea Arcangeli" wrote:
> >
> > + if (cmd != UFFDIO_API) {
> > + if (ctx->state == UFFD_STATE_WAIT_API)
> > + return -EINVAL;
> > + BUG_ON(ctx->state
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 w
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 to
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 E
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
Suggested-by: Andrew Hon
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 a
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 ex
On Mon, Jun 15, 2015 at 12:19 PM, Andrea Arcangeli wrote:
>
> Yes, it would leave the other blocked, how is it different from having
> just 1 reader and it gets killed?
Either is completely wrong. But the read() code can at least see that
"I'm returning early due to a signal, so I'll wake up any
54 matches
Mail list logo
