On 2015/3/10 4:54, Marcelo Tosatti wrote:
On Sat, Dec 27, 2014 at 09:41:45PM +0100, Paolo Bonzini wrote:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index f528343..6e52f3f 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -672,6 +672,7 @@ static void update_memslots(struct
Hi folks,
This is a small patch that implements logic to handle the RH bit
being set in the msi message address register. Currently the DM bit is
the only thing used to decide irq->dest_mode (logical when DM set,
physical when unset). Documentation indicates that the DM bit will be
ignored when th
Thomas Huth writes:
> On Wed, 25 Feb 2015 16:11:27 +0100
> Cornelia Huck wrote:
>
>> On Wed, 25 Feb 2015 15:36:02 +0100
>> "Michael S. Tsirkin" wrote:
>>
>> > virtio balloon has this code:
>> > wait_event_interruptible(vb->config_change,
>> > (diff = tow
Cornelia Huck writes:
> On Wed, 4 Mar 2015 11:25:56 +0100
> "Michael S. Tsirkin" wrote:
>
>> On Wed, Mar 04, 2015 at 04:44:54PM +1030, Rusty Russell wrote:
>> > "Michael S. Tsirkin" writes:
>> > > On Mon, Mar 02, 2015 at 10:37:26AM +1030, Rusty Russell wrote:
>> > >> Thomas Huth writes:
>> > >>
On 10/03/2015 07:07, Marcelo Tosatti wrote:
On Fri, Feb 27, 2015 at 03:18:17PM +0800, Xiubo Li wrote:
There are to much warning/error noise in kvm_main.c when gernerating and
checking new patches.
This patch series fix most of these warnings and errors to reduce possible
noise.
Change in v2:
On Fri, Feb 27, 2015 at 06:19:18PM -0600, Joel Schopp wrote:
> From: David Kaplan
> No need to re-decode WBINVD since we know what it is from the intercept.
>
> Signed-off-by: David Kaplan
> [extracted from larger unlrelated patch, forward ported, tested]
> Signed-off-by: Joel Schopp
Can't you
On Fri, Feb 27, 2015 at 03:18:17PM +0800, Xiubo Li wrote:
>
> There are to much warning/error noise in kvm_main.c when gernerating and
> checking new patches.
>
> This patch series fix most of these warnings and errors to reduce possible
> noise.
>
>
> Change in v2:
> - Accept Thomas Huth's adv
Linus,
Please pull from
git://git.kernel.org/pub/scm/virt/kvm/kvm.git master
To receive the following KVM S/390 bug fixes
Christian Borntraeger (1):
KVM: s390/cpacf: Fix kernel bug under z/VM
Marcelo Tosatti (1):
Merge tag 'kvm-s390-master-20150303' of
git://git.kernel.org/.../k
On Tue, Feb 24, 2015 at 09:29:25PM +0100, Thomas Huth wrote:
> kvm_kvfree() provides exactly the same functionality as the
> new common kvfree() function - so let's simply replace the
> kvm function with the common function.
>
> Signed-off-by: Thomas Huth
Applied, thanks.
--
To unsubscribe from
On Fri, Feb 27, 2015 at 04:50:10PM +0100, Christian Borntraeger wrote:
> halt_poll_ns is used only locally. Make it static.
>
> Signed-off-by: Christian Borntraeger
> ---
> virt/kvm/kvm_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
--
To unsubscribe from this
On Sat, Dec 27, 2014 at 09:41:45PM +0100, Paolo Bonzini wrote:
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index f528343..6e52f3f 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -672,6 +672,7 @@ static void update_memslots(struct kvm_memslots *slots,
> >
Signed-off-by: Geert Uytterhoeven
---
arch/s390/kvm/kvm-s390.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/kvm/kvm-s390.h b/arch/s390/kvm/kvm-s390.h
index fda3f3146eb636d3..83f32a147d72c0f3 100644
--- a/arch/s390/kvm/kvm-s390.h
+++ b/arch/s390/kvm/kvm-s390.h
@@ -
KVM tends to patch and emulated vmmcall on Intel. But that must not
happen for L2.
Signed-off-by: Jan Kiszka
---
If the recently posted fixed for KVM are applied, this test passes.
x86/vmx_tests.c | 40
1 file changed, 40 insertions(+)
diff --git a/x86
While in L2, leave all #UD to L2 and do not try to emulate it. If L1 is
interested in doing this, it reports its interest via the exception
bitmap, and we never get into handle_exception of L0 anyway.
Signed-off-by: Jan Kiszka
---
Noticed while wondering where the vmmcall of a misconfigured L2 w
On 10 March 2015 at 04:29, Christoffer Dall wrote:
> On Mon, Mar 09, 2015 at 04:34:21PM +, Alex Bennée wrote:
>> - Boot
>> - Power on secondary CPUs
>> - Power off one secondary CPU
>> - Migrate to file (cpu_powered reflects state of each CPU)
>>
>> - Start fresh QEMU
>> - Restore from file (c
On 03/09/2015 09:33 PM, Paolo Bonzini wrote:
On 09/03/2015 18:08, Avi Kivity wrote:
Is the issue emulating a higher MAXPHYADDR on the guest than is
available on the host? I don't think there's any need to support that.
No, indeed. The only problem is that the failure mode is quite horrible
(y
On 03/09/2015 09:38 PM, Paolo Bonzini wrote:
On 09/03/2015 20:19, Avi Kivity wrote:
I can't think of one with reasonable performance either. Perhaps the
maintainers could raise the issue with Intel. It looks academic but it
can happen in real life -- KVM for example used to rely on reserved b
On 09/03/2015 20:19, Avi Kivity wrote:
> I can't think of one with reasonable performance either. Perhaps the
> maintainers could raise the issue with Intel. It looks academic but it
> can happen in real life -- KVM for example used to rely on reserved bits
> faults (it set all bits in the PTE
On 09/03/2015 18:08, Avi Kivity wrote:
> Is the issue emulating a higher MAXPHYADDR on the guest than is
> available on the host? I don't think there's any need to support that.
No, indeed. The only problem is that the failure mode is quite horrible
(you get a triple fault, possibly while the g
On Mon, Mar 09, 2015 at 10:31:19PM +0900, Peter Maydell wrote:
> On 9 March 2015 at 21:56, Christoffer Dall
> wrote:
> > this function, however, is not used only when migration, but should
> > generally cover the case where you want to synchronize QEMU's state into
> > KVM's state, right? So whi
On Mon, Mar 09, 2015 at 04:34:21PM +, Alex Bennée wrote:
>
> Christoffer Dall writes:
>
> > Hi Alex,
> >
> > The subject of this change has a typo, and I also think it's not about
> > exposing the pause state (that's just an internal name/concept), but
> > about exposing the PSCI state, or s
For a very long time (since 2b3d2a20), the path handling a vmmcall
instruction of the guest on an Intel host only applied the patch but no
longer handled the hypercall. The reverse case, vmcall on AMD hosts, is
fine. As both em_vmcall and em_vmmcall actually have to do the same, we
can fix the issu
On 03/09/2015 09:07 PM, Nadav Amit wrote:
Avi Kivity wrote:
On 03/09/2015 07:51 PM, Nadav Amit wrote:
Avi Kivity wrote:
On 03/03/2015 11:52 AM, Paolo Bonzini wrote:
In this
case, the VM might expect exceptions when PTE bits which are higher than the
maximum (reported) address width are se
Avi Kivity wrote:
> On 03/09/2015 07:51 PM, Nadav Amit wrote:
>> Avi Kivity wrote:
>>
>>> On 03/03/2015 11:52 AM, Paolo Bonzini wrote:
> In this
> case, the VM might expect exceptions when PTE bits which are higher than
> the
> maximum (reported) address width are set, and it w
On 03/09/2015 07:51 PM, Nadav Amit wrote:
Avi Kivity wrote:
On 03/03/2015 11:52 AM, Paolo Bonzini wrote:
In this
case, the VM might expect exceptions when PTE bits which are higher than the
maximum (reported) address width are set, and it would not get such
exceptions. This problem can easily
Code compiles to the same binary, but now with one warning less.
Signed-off-by: Jan Kiszka
---
x86/emulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/x86/emulator.c b/x86/emulator.c
index 0964e6a..e5c1c6b 100644
--- a/x86/emulator.c
+++ b/x86/emulator.c
@@ -838,7 +838
Avi Kivity wrote:
> On 03/03/2015 11:52 AM, Paolo Bonzini wrote:
>>> In this
>>> case, the VM might expect exceptions when PTE bits which are higher than the
>>> maximum (reported) address width are set, and it would not get such
>>> exceptions. This problem can easily be experienced by small cha
On 03/03/2015 11:52 AM, Paolo Bonzini wrote:
In this
case, the VM might expect exceptions when PTE bits which are higher than the
maximum (reported) address width are set, and it would not get such
exceptions. This problem can easily be experienced by small change to the
existing KVM unit-tests.
Christoffer Dall writes:
> On Mon, Mar 02, 2015 at 01:29:01PM +, Alex Bennée wrote:
>> From: Christoffer Dall
>>
>> Migrating active interrupts causes the active state to be lost
>> completely. This implements some additional bitmaps to track the active
>> state on the distributor and expo
Christoffer Dall writes:
> Hi Alex,
>
> The subject of this change has a typo, and I also think it's not about
> exposing the pause state (that's just an internal name/concept), but
> about exposing the PSCI state, or simply the VCPU power state.
arm: KVM: export VCPU power state via MP_STATE i
Peter Maydell writes:
> On 9 March 2015 at 21:56, Christoffer Dall
> wrote:
>> this function, however, is not used only when migration, but should
>> generally cover the case where you want to synchronize QEMU's state into
>> KVM's state, right? So while it may not be harmful in currently
>>
On 09/03/2015 16:39, Thomas Huth wrote:
> On Tue, 24 Feb 2015 21:29:25 +0100
> Thomas Huth wrote:
>
>> kvm_kvfree() provides exactly the same functionality as the
>> new common kvfree() function - so let's simply replace the
>> kvm function with the common function.
>>
>> Signed-off-by: Thomas
2015-03-06 14:44-0600, Joel Schopp:
> From: David Kaplan
>
> Another patch in my war on emulate_on_interception() use as a svm exit
> handler.
>
> These were pulled out of a larger patch at the suggestion of Radim Krcmar, see
> https://lkml.org/lkml/2015/2/25/559
>
> Changes since v1:
>
On 03/09/2015 07:26 AM, Andrew Jones wrote:
> On Fri, Mar 06, 2015 at 01:08:29PM -0800, Mario Smarduch wrote:
>> On 03/05/2015 09:43 AM, Paolo Bonzini wrote:
>>>
>>>
>>> On 05/03/2015 15:58, Catalin Marinas wrote:
> It would especially suck if the user has a cluster with different
> machine
On Tue, 24 Feb 2015 21:29:25 +0100
Thomas Huth wrote:
> kvm_kvfree() provides exactly the same functionality as the
> new common kvfree() function - so let's simply replace the
> kvm function with the common function.
>
> Signed-off-by: Thomas Huth
> ---
> arch/x86/kvm/x86.c |8 -
On Mon, Mar 02, 2015 at 01:29:02PM +, Alex Bennée wrote:
> This helps re-factor away some of the repetitive code and makes the code
> flow more nicely.
>
> Signed-off-by: Alex Bennée
>
Reviewed-by: Christoffer Dall
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the bod
On Mon, Mar 02, 2015 at 01:29:01PM +, Alex Bennée wrote:
> From: Christoffer Dall
>
> Migrating active interrupts causes the active state to be lost
> completely. This implements some additional bitmaps to track the active
> state on the distributor and export this to user space.
>
> Signed-
At the moment the iommu_table struct has a set_bypass() which enables/
disables DMA bypass on IODA2 PHB. This is exposed to POWERPC IOMMU code
which calls this callback when external IOMMU users such as VFIO are
about to get over a PHB.
The set_bypass() callback is not really an iommu_table functi
Normally a bitmap from the iommu_table is used to track what TCE entry
is in use. Since we are going to use iommu_table without its locks and
do xchg() instead, it becomes essential not to put bits which are not
implied in the direction flag.
This adds iommu_direction_to_tce_perm() (its counterpar
This is a part of moving TCE table allocation into an iommu_ops
callback to support multiple IOMMU groups per one VFIO container.
This enforce window size to be a power of two.
This is a pretty mechanical patch.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/platforms/powernv/pci-ioda.c
TCE tables might get too big in case of 4K IOMMU pages and DDW enabled
on huge guests (hundreds of GB of RAM) so the kernel might be unable to
allocate contiguous chunk of physical memory to store the TCE table.
To address this, POWER8 CPU (actually, IODA2) supports multi-level TCE tables,
up to 5
This adds missing locks in iommu_take_ownership()/
iommu_release_ownership().
This marks all pages busy in iommu_table::it_map in order to catch
errors if there is an attempt to use this table while ownership over it
is taken.
This only clears TCE content if there is no page marked busy in it_map
This changes few functions to receive a iommu_table_group pointer
rather than PE as they are going to be a part of upcoming
iommu_table_group_ops callback set.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/platforms/powernv/pci-ioda.c | 13 -
1 file changed, 8 insertions(+), 5
This extends iommu_table_group_ops by a set of callbacks to support dynamic
DMA windows management.
query() returns IOMMU capabilities such as default DMA window address and
supported number of DMA windows and TCE table levels.
create_table() creates a TCE table with specific parameters.
it recei
On Fri, Mar 06, 2015 at 01:08:29PM -0800, Mario Smarduch wrote:
> On 03/05/2015 09:43 AM, Paolo Bonzini wrote:
> >
> >
> > On 05/03/2015 15:58, Catalin Marinas wrote:
> >>> It would especially suck if the user has a cluster with different
> >>> machines, some of them coherent and others non-coher
This moves page pinning (get_user_pages_fast()/put_page()) code out of
the platform IOMMU code and puts it to VFIO IOMMU driver where it belongs
to as the platform code does not deal with page pinning.
This makes iommu_take_ownership()/iommu_release_ownership() deal with
the IOMMU table bitmap onl
This makes use of the it_page_size from the iommu_table struct
as page size can differ.
This replaces missing IOMMU_PAGE_SHIFT macro in commented debug code
as recently introduced IOMMU_PAGE_XXX macros do not include
IOMMU_PAGE_SHIFT.
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
This moves iommu_table creation to the beginning. This is a mechanical
patch.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/platforms/powernv/pci-ioda.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-
The existing IOMMU code takes/releases ownership over the existing IOMMU
tables created by the platform code, i.e. the tables remain in memory
all the time. Also, the existing IOMMU requires VFIO_IOMMU_ENABLE call to
start working as that's where we check the rlimit for locked pages.
New IOMMU wil
This enables sPAPR defined feature called Dynamic DMA windows (DDW).
Each Partitionable Endpoint (IOMMU group) has an address range on a PCI bus
where devices are allowed to do DMA. These ranges are called DMA windows.
By default, there is a single DMA window, 1 or 2GB big, mapped at zero
on a PC
This checks that the TCE table page size is not bigger that the size of
a page we just pinned and going to put its physical address to the table.
Otherwise the hardware gets unwanted access to physical memory between
the end of the actual page and the end of the aligned up TCE page.
Since compoun
This adds a iommu_table_ops struct and puts pointer to it into
the iommu_table struct. This moves tce_build/tce_free/tce_get/tce_flush
callbacks from ppc_md to the new struct where they really belong to.
This adds the requirement for @it_ops to be initialized before calling
iommu_init_table() to m
This is a pretty mechanical patch to make next patches simpler.
New tce_iommu_unuse_page() helper does put_page() now but it might skip
that after the memory registering patch applied.
As we are here, this removes unnecessary checks for a value returned
by pfn_to_page() as it cannot possibly retu
There moves locked pages accounting to helpers.
Later they will be reused for Dynamic DMA windows (DDW).
This reworks debug messages to show the current value and the limit.
This stores the locked pages number in the container so when unlocking
the iommu table pointer won't be needed. This does n
This is to make extended ownership and multiple groups support patches
simpler for review.
This is a mechanical patch.
Signed-off-by: Alexey Kardashevskiy
---
drivers/vfio/vfio_iommu_spapr_tce.c | 38 ++---
1 file changed, 23 insertions(+), 15 deletions(-)
diff
The existing implementation accounts the whole DMA window in
the locked_vm counter which is going to be even worse with multiple
containers and huge DMA windows.
This introduces 2 ioctls to register/unregister DMA memory which
receive user space address and size of a memory region which
needs to b
Modern IBM POWERPC systems support multiple (currently two) TCE tables
per IOMMU group (a.k.a. PE). This adds a iommu_table_group container
for TCE tables. Right now just one table is supported.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/iommu.h| 18 +++--
arch
This adds create/remove window ioctls to create and remove DMA windows.
sPAPR defines a Dynamic DMA windows capability which allows
para-virtualized guests to create additional DMA windows on a PCI bus.
The existing linux kernels use this new window to map the entire guest
memory and switch to the
This replaces multiple calls of kzalloc_node() with a new
iommu_table_alloc() helper. Right now it calls kzalloc_node() but
later it will be modified to allocate a iommu_table_group struct with
a single iommu_table in it.
Later the helper will allocate a iommu_table_group struct which embeds
the i
This replaces iommu_take_ownership()/iommu_release_ownership() calls
with the callback calls and it is up to the platform code to call
iommu_take_ownership()/iommu_release_ownership() if needed.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/iommu.h| 4 +--
arch/powerpc/ke
At the moment only one group per container is supported.
POWER8 CPUs have more flexible design and allows naving 2 TCE tables per
IOMMU group so we can relax this limitation and support multiple groups
per container.
This adds TCE table descriptors to a container and uses iommu_table_group_ops
to
At the moment writing new TCE value to the IOMMU table fails with EBUSY
if there is a valid entry already. However PAPR specification allows
the guest to write new TCE value without clearing it first.
Another problem this patch is addressing is the use of pool locks for
external IOMMU users such a
This is a part of moving DMA window programming to an iommu_ops
callback.
This is a mechanical patch.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/platforms/powernv/pci-ioda.c | 85 ---
1 file changed, 56 insertions(+), 29 deletions(-)
diff --git a/arch/powe
The pnv_pci_ioda_tce_invalidate() helper invalidates TCE cache. It is
supposed to be called on IODA1/2 and not called on p5ioc2. It receives
start and end host addresses of TCE table. This approach makes it possible
to get pnv_pci_ioda_tce_invalidate() unintentionally called on p5ioc2.
Another issu
Before the IOMMU user would take control over the IOMMU table belonging to
a specific IOMMU group. This approach did not allow sharing tables between
IOMMU groups attached to the same container.
This introduces a new IOMMU ownership flavour when the user can not
just control the existing IOMMU tab
The iommu_free_table helper release memory it is using (the TCE table and
@it_map) and release the iommu_table struct as well. We might not want
the very last step as we store iommu_table in parent structures.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/iommu.h | 1 +
arch/
At the moment DMA map/unmap requests are handled irrespective to
the container's state. This allows the user space to pin memory which
it might not be allowed to pin.
This adds checks to MAP/UNMAP that the container is enabled, otherwise
-EPERM is returned.
Signed-off-by: Alexey Kardashevskiy
--
This clears the TCE table when a container is being closed as this is
a good thing to leave the table clean before passing the ownership
back to the host kernel.
Signed-off-by: Alexey Kardashevskiy
---
drivers/vfio/vfio_iommu_spapr_tce.c | 14 +++---
1 file changed, 11 insertions(+), 3 d
Hi Alex,
The subject of this change has a typo, and I also think it's not about
exposing the pause state (that's just an internal name/concept), but
about exposing the PSCI state, or simply the VCPU power state.
On Mon, Mar 02, 2015 at 01:29:00PM +, Alex Bennée wrote:
> To cleanly restore an
On 9 March 2015 at 21:56, Christoffer Dall wrote:
> this function, however, is not used only when migration, but should
> generally cover the case where you want to synchronize QEMU's state into
> KVM's state, right? So while it may not be harmful in currently
> supported use cases, is there ever
On Wed, Mar 04, 2015 at 02:35:52PM +, Alex Bennée wrote:
> From: Christoffer Dall
>
> The current code was negatively indexing the cpu state array and not
> synchronizing banked spsr register state with the current mode's spsr
> state, causing occasional failures with migration.
>
> Some mun
On Tue, Mar 03, 2015 at 11:28:21AM +, Alex Bennée wrote:
>
> Christoffer Dall writes:
>
> > Hi Alex,
> >
> > Seems like you accidentally sent out two copies of this patch, hopefully
> > I'm reviewing the right one...
>
> Oops, perils of not wiping your output directory. I think it was just
Am 03.03.2015 um 22:46 schrieb Christian Borntraeger:
[...]
>
> halt_poll_ns is used only locally. Make it static and remove
> the initializer.
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 34310a8..58bc2a9 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@
On Mon, 09 Mar 2015 17:43:19 +1030
Rusty Russell wrote:
> "Michael S. Tsirkin" writes:
> > virtio-balloon: do not call blocking ops when !TASK_RUNNING
> >
> > Rusty, it seems you prefer a different fix for this issue,
> > while Cornelia prefers mine. Maybe both me and Cornelia misunderstand
On Sat, Mar 07, 2015 at 08:06:56PM +0100, Michael S. Tsirkin wrote:
> virtio spec requires that all drivers set DRIVER_OK
> before using devices. While rpmsg isn't yet
> included in the virtio 1 spec, previous spec versions
> also required this.
>
> virtio rpmsg violates this rule: is calls kick
>
On Mon, Mar 09, 2015 at 05:39:20PM +1030, Rusty Russell wrote:
> "Michael S. Tsirkin" writes:
> > virtio spec requires that all drivers set DRIVER_OK
> > before using devices. While rpmsg isn't yet
> > included in the virtio 1 spec, previous spec versions
> > also required this.
> >
> > virtio rpm
"Michael S. Tsirkin" writes:
> Hi Rusty!
> There are a bunch of (mostly virtio 1.0 related) fixes for virtio
> that need to go into 4.0 I think.
> virtio_blk: typo fix
> virtio_blk: fix comment for virtio 1.0
OK, I've added these two. I tend to be overcautious after the merge
window.
"Michael S. Tsirkin" writes:
> virtio spec requires that all drivers set DRIVER_OK
> before using devices. While rpmsg isn't yet
> included in the virtio 1 spec, previous spec versions
> also required this.
>
> virtio rpmsg violates this rule: is calls kick
> before setting DRIVER_OK.
>
> The fix
78 matches
Mail list logo
