On 27/01/2015 11:57, Joerg Roedel wrote:
> From: Joerg Roedel
>
> When assigning devices to large memory guests (>=128GB guest
> memory in the failure case) the functions to create the
> IOMMU page-tables for the whole guest might run for a very
> long time. On non-preemptible kernels this migh
From: Joerg Roedel
When assigning devices to large memory guests (>=128GB guest
memory in the failure case) the functions to create the
IOMMU page-tables for the whole guest might run for a very
long time. On non-preemptible kernels this might cause
Soft-Lockup warnings. Fix these by adding a con
On Wed, Dec 17, 2014 at 11:46:24AM +0100, Paolo Bonzini wrote:
>
>
> On 17/12/2014 11:35, Joerg Roedel wrote:
> >> >
> >> > This file is already gone after one latest commit c274e03af705,
> >> > "kvm: x86: move assigned-dev.c and iommu.c to arch/x86/" is
> >> > introduced, so you need to pull yo
On 17/12/2014 11:35, Joerg Roedel wrote:
>> >
>> > This file is already gone after one latest commit c274e03af705,
>> > "kvm: x86: move assigned-dev.c and iommu.c to arch/x86/" is
>> > introduced, so you need to pull your tree firstly :)
> Hmm, I based the patch on kvm/master, where the file is
On Wed, Dec 17, 2014 at 09:38:57AM +0800, Chen, Tiejun wrote:
> On 2014/12/16 23:47, Joerg Roedel wrote:
> >diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
> >index c1e6ae9..ac427e8 100644
> >--- a/virt/kvm/iommu.c
> >+++ b/virt/kvm/iommu.c
>
> This file is already gone after one latest commit c2
On 2014/12/16 23:47, Joerg Roedel wrote:
From: Joerg Roedel
When assigning devices to large memory guests (>=128GB guest
memory in the failure case) the functions to create the
IOMMU page-tables for the whole guest might run for a very
long time. On non-preemptible kernels this might cause
Soft
From: Joerg Roedel
When assigning devices to large memory guests (>=128GB guest
memory in the failure case) the functions to create the
IOMMU page-tables for the whole guest might run for a very
long time. On non-preemptible kernels this might cause
Soft-Lockup warnings. Fix these by adding a con
From: "Michael S. Tsirkin"
3.4.104-rc1 review patch. If anyone has any objections, please let me know.
--
commit 350b8bdd689cd2ab2c67c8a86a0be86cfa0751a7 upstream.
The third parameter of kvm_iommu_put_pages is wrong,
It should be 'gfn - slot->base_gfn'.
By making gfn very lar
Hi Paolo, Gleb,
On Fri, Sep 05, 2014 at 12:53:01PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Cc: Gleb Natapov
> Cc: Paolo Bonzini
> Signed-off-by: Joerg Roedel
> ---
> virt/kvm/iommu.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
Do you have any objections against
3.13.11.7 -stable review patch. If anyone has any objections, please let me
know.
--
From: "Michael S. Tsirkin"
commit 350b8bdd689cd2ab2c67c8a86a0be86cfa0751a7 upstream.
The third parameter of kvm_iommu_put_pages is wrong,
It should be 'gfn - slot->base_gfn'.
By making gfn v
3.2.63-rc1 review patch. If anyone has any objections, please let me know.
--
From: "Michael S. Tsirkin"
commit 350b8bdd689cd2ab2c67c8a86a0be86cfa0751a7 upstream.
The third parameter of kvm_iommu_put_pages is wrong,
It should be 'gfn - slot->base_gfn'.
By making gfn very larg
From: Joerg Roedel
Cc: Gleb Natapov
Cc: Paolo Bonzini
Signed-off-by: Joerg Roedel
---
virt/kvm/iommu.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
index 714b949..45ee080 100644
--- a/virt/kvm/iommu.c
+++ b/virt/kvm/iommu.c
@@ -
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: "Michael S. Tsirkin"
commit 350b8bdd689cd2ab2c67c8a86a0be86cfa0751a7 upstream.
The third parameter of kvm_iommu_put_pages is wrong,
It should be 'gfn - slot->base_gfn'.
By making gfn very lar
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: "Michael S. Tsirkin"
commit 350b8bdd689cd2ab2c67c8a86a0be86cfa0751a7 upstream.
The third parameter of kvm_iommu_put_pages is wrong,
It should be 'gfn - slot->base_gfn'.
By making gfn very lar
3.16-stable review patch. If anyone has any objections, please let me know.
--
From: "Michael S. Tsirkin"
commit 350b8bdd689cd2ab2c67c8a86a0be86cfa0751a7 upstream.
The third parameter of kvm_iommu_put_pages is wrong,
It should be 'gfn - slot->base_gfn'.
By making gfn very lar
From: "Michael S. Tsirkin"
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 350b8bdd689cd2ab2c67c8a86a0be86cfa0751a7 upstream.
The third parameter of kvm_iommu_put_pages is wrong,
It should be 'gfn - slot->base_gfn'.
By making gfn very large,
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Greg Edwards
commit 27ef63c7e97d1e585051c03f8d44cc887f34 upstream.
When determining the page size we could use to map with the IOMMU, the
page size should also be aligned with the hva, not
3.5.7.29 -stable review patch. If anyone has any objections, please let me
know.
--
From: Greg Edwards
commit 27ef63c7e97d1e585051c03f8d44cc887f34 upstream.
When determining the page size we could use to map with the IOMMU, the
page size should also be aligned with the hv
3.2.54-rc1 review patch. If anyone has any objections, please let me know.
--
From: Greg Edwards
commit 27ef63c7e97d1e585051c03f8d44cc887f34 upstream.
When determining the page size we could use to map with the IOMMU, the
page size should also be aligned with the hva, not
3.8.13.14 -stable review patch. If anyone has any objections, please let me
know.
--
From: Greg Edwards
commit 27ef63c7e97d1e585051c03f8d44cc887f34 upstream.
When determining the page size we could use to map with the IOMMU, the
page size should also be aligned with the h
3.11.10.1 -stable review patch. If anyone has any objections, please let me
know.
--
From: Greg Edwards
commit 27ef63c7e97d1e585051c03f8d44cc887f34 upstream.
When determining the page size we could use to map with the IOMMU, the
page size should also be aligned with the h
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Greg Edwards
commit 27ef63c7e97d1e585051c03f8d44cc887f34 upstream.
When determining the page size we could use to map with the IOMMU, the
page size should also be aligned with the hva, not
3.12-stable review patch. If anyone has any objections, please let me know.
--
From: Greg Edwards
commit 27ef63c7e97d1e585051c03f8d44cc887f34 upstream.
When determining the page size we could use to map with the IOMMU, the
page size should also be aligned with the hva, not
On Mon, Nov 04, 2013 at 09:08:12AM -0700, Greg Edwards wrote:
> When determining the page size we could use to map with the IOMMU, the
> page size should also be aligned with the hva, not just the gfn. The
> gfn may not reflect the real alignment within the hugetlbfs file.
>
For some reason you d
On Mon, Nov 04, 2013 at 09:08:12AM -0700, Greg Edwards wrote:
> When determining the page size we could use to map with the IOMMU, the
> page size should also be aligned with the hva, not just the gfn. The
> gfn may not reflect the real alignment within the hugetlbfs file.
>
> Signed-off-by: Greg
When determining the page size we could use to map with the IOMMU, the
page size should also be aligned with the hva, not just the gfn. The
gfn may not reflect the real alignment within the hugetlbfs file.
Signed-off-by: Greg Edwards
Cc: sta...@vger.kernel.org
---
virt/kvm/iommu.c | 4
1 f
On Fri, Nov 01, 2013 at 10:08:55AM -0600, Greg Edwards wrote:
> When determining the page size we could use to map with the IOMMU, the
> page size should be aligned with the hva, not the gfn. The gfn may not
> reflect the real alignment within the hugetlbfs file.
>
> Most of the time, this works
When determining the page size we could use to map with the IOMMU, the
page size should be aligned with the hva, not the gfn. The gfn may not
reflect the real alignment within the hugetlbfs file.
Most of the time, this works fine. However, if the hugetlbfs file is
backed by non-contiguous huge p
See patch 3/3 for a description of exactly why we need this. I know
POWER folks are also interested in making use of VFIO's external user
interface from KVM and Alexey's proposed patches have a similar device
tailored for SPAPR use there. I'm hoping that we can make the base
device common and ext
On Wed, 30 Jan 2013 12:06:32 +0800
Xiao Guangrong wrote:
> So, i guess we can do the simple fix first.
>
> >>> By simple fix you mean calling kvm_arch_flush_shadow_all() on READONLY
> >>> flag change?
> >>
> >> Simply disallow READONLY flag changing.
> > Ok, can somebody craft a patch?
ov wrote:
>>>>> On Fri, Jan 25, 2013 at 11:28:40AM +0800, Xiao Guangrong wrote:
>>>>>> On 01/25/2013 09:17 AM, Takuya Yoshikawa wrote:
>>>>>>> On Thu, 24 Jan 2013 15:03:57 -0700
>>>>>>> Alex Williamson wrote:
>>>>>
wa wrote:
>>>>> On Thu, 24 Jan 2013 15:03:57 -0700
>>>>> Alex Williamson wrote:
>>>>>
>>>>>> A couple patches to make KVM IOMMU support honor read-only mappings.
>>>>>> This causes an un-map, re-map when the read-on
57 -0700
> >>> Alex Williamson wrote:
> >>>
> >>>> A couple patches to make KVM IOMMU support honor read-only mappings.
> >>>> This causes an un-map, re-map when the read-only flag changes and
> >>>> makes use of it when setting IOM
On 01/28/2013 06:59 PM, Gleb Natapov wrote:
> On Fri, Jan 25, 2013 at 11:28:40AM +0800, Xiao Guangrong wrote:
>> On 01/25/2013 09:17 AM, Takuya Yoshikawa wrote:
>>> On Thu, 24 Jan 2013 15:03:57 -0700
>>> Alex Williamson wrote:
>>>
>>>> A couple p
On Mon, 28 Jan 2013 08:36:56 -0700
Alex Williamson wrote:
> On Mon, 2013-01-28 at 21:25 +0900, Takuya Yoshikawa wrote:
> > On Mon, 28 Jan 2013 12:59:03 +0200
> > Gleb Natapov wrote:
> >
> > > > It sets spte based on the old value that means the readonly flag check
> > > > is missed. We need to
On Mon, 2013-01-28 at 21:25 +0900, Takuya Yoshikawa wrote:
> On Mon, 28 Jan 2013 12:59:03 +0200
> Gleb Natapov wrote:
>
> > > It sets spte based on the old value that means the readonly flag check
> > > is missed. We need to call kvm_arch_flush_shadow_all under this case.
> > Why not just disallo
On Mon, 28 Jan 2013 12:59:03 +0200
Gleb Natapov wrote:
> > It sets spte based on the old value that means the readonly flag check
> > is missed. We need to call kvm_arch_flush_shadow_all under this case.
> Why not just disallow changing memory region KVM_MEM_READONLY flag
> without deleting the r
On Fri, Jan 25, 2013 at 11:28:40AM +0800, Xiao Guangrong wrote:
> On 01/25/2013 09:17 AM, Takuya Yoshikawa wrote:
> > On Thu, 24 Jan 2013 15:03:57 -0700
> > Alex Williamson wrote:
> >
> >> A couple patches to make KVM IOMMU support honor read-only mappings.
>
On Thu, Jan 24, 2013 at 03:03:57PM -0700, Alex Williamson wrote:
> A couple patches to make KVM IOMMU support honor read-only mappings.
> This causes an un-map, re-map when the read-only flag changes and
> makes use of it when setting IOMMU attributes. Thanks,
>
> Alex
>
On Fri, 25 Jan 2013 12:59:12 +0900
Takuya Yoshikawa wrote:
> > The commit c972f3b1 changed the write-protect behaviour - it does
> > wirte-protection only when dirty flag is set.
> > [ I did not see this commit when we discussed the problem before. ]
>
> I'll look at the commit later, after the
On Fri, 25 Jan 2013 11:28:40 +0800
Xiao Guangrong wrote:
> > I think I can naturally update my patch after this gets merged.
> >
>
> Please wait.
The patch I mentioned above won't change anything. Just cleans up
set_memory_region(). The only possible change which we discussed
before was whet
On 01/25/2013 09:17 AM, Takuya Yoshikawa wrote:
> On Thu, 24 Jan 2013 15:03:57 -0700
> Alex Williamson wrote:
>
>> A couple patches to make KVM IOMMU support honor read-only mappings.
>> This causes an un-map, re-map when the read-only flag changes and
>> makes u
On Thu, 24 Jan 2013 15:03:57 -0700
Alex Williamson wrote:
> A couple patches to make KVM IOMMU support honor read-only mappings.
> This causes an un-map, re-map when the read-only flag changes and
> makes use of it when setting IOMMU attributes. Thanks,
Looks good to me.
I th
A couple patches to make KVM IOMMU support honor read-only mappings.
This causes an un-map, re-map when the read-only flag changes and
makes use of it when setting IOMMU attributes. Thanks,
Alex
---
Alex Williamson (2):
kvm: Force IOMMU remapping on memory slot read-only flag changes
On 08/03/2012 10:36 AM, Xiao Guangrong wrote:
> There are two bugs:
> - the 'error page' is forgot to be released
> [ it is unneeded after commit a2766325cf9f9, for backport, we
> still do kvm_release_pfn_clean for the error pfn ]
>
> - guest pages are always released regardless of the unmap
On Fri, Aug 03, 2012 at 03:36:52PM +0800, Xiao Guangrong wrote:
> There are two bugs:
> - the 'error page' is forgot to be released
> [ it is unneeded after commit a2766325cf9f9, for backport, we
> still do kvm_release_pfn_clean for the error pfn ]
>
> - guest pages are always released regar
There are two bugs:
- the 'error page' is forgot to be released
[ it is unneeded after commit a2766325cf9f9, for backport, we
still do kvm_release_pfn_clean for the error pfn ]
- guest pages are always released regardless of the unmapped page
(e,g, caused by hwpoison)
Signed-off-by: Xiao
There are two bugs:
- the 'error page' is forgot to be released
[ it is unneeded after commit a2766325cf9f9, for backport, we
still do kvm_release_pfn_clean for the error pfn ]
- guest pages are always released regardless of the unmapped page
(e,g, caused by hwpoison)
Signed-off-by: Xiao
On Wed, 2007-06-13 at 11:52 -0700, David Brown wrote:
> > Hi David,
> > I am not an expert here, but I don't believe it would work without
> > changes to KVM. My understanding is that you use an IOMMU in this
> > fashion if you want to direct-map a device into a guest for devices that
> > do not
On Wed, 2007-06-13 at 10:27 -0700, David Brown wrote:
> I was wondering if anyone has done any sort of virtualization testing
> with kvm using IOMMU to improve performance of I/O and what sort of
> results they've had... I currently don't have a box with IOMMU (at
> least I don't think so, since it
Hi David,
I am not an expert here, but I don't believe it would work without
changes to KVM. My understanding is that you use an IOMMU in this
fashion if you want to direct-map a device into a guest for devices that
do not have a local IOMMU-like functionality built in already. For
instance, p
I was wondering if anyone has done any sort of virtualization testing
with kvm using IOMMU to improve performance of I/O and what sort of
results they've had... I currently don't have a box with IOMMU (at
least I don't think so, since its an i386 box) but will be getting
some amd64 boxes which, ho
52 matches
Mail list logo
