In kvm_test_clear_dirty_npages(), if we find an invalid HPTE we move on to the
next HPTE without unlocking the invalid one. In fact we should never
find an invalid and unlocked HPTE in the rmap chain, but for robustness
we should unlock it. This adds the missing unlock.
Reported-by: Benjamin
On 10/13/14 at 10:50am, Michael S. Tsirkin wrote:
virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after probe returns, virtio console violated this
rule by adding inbufs, which causes the VQ to be used directly within
probe.
To fix, call
On Mon, 20 Oct 2014 13:07:50 +0100
Thomas Graf tg...@suug.ch wrote:
On 10/13/14 at 10:50am, Michael S. Tsirkin wrote:
virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after probe returns, virtio console violated this
rule by adding inbufs, which
On Mon, Oct 20, 2014 at 01:07:50PM +0100, Thomas Graf wrote:
On 10/13/14 at 10:50am, Michael S. Tsirkin wrote:
virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after probe returns, virtio console violated this
rule by adding inbufs, which causes the
On 10/20/14 at 02:42pm, Cornelia Huck wrote:
On Mon, 20 Oct 2014 13:07:50 +0100
Thomas Graf tg...@suug.ch wrote:
On 10/13/14 at 10:50am, Michael S. Tsirkin wrote:
virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after probe returns, virtio
Hi all,
we just started a test with Jailhouse in a VM on a decently recent Intel
box. It has APICv / posted interrupts support. And it breaks Jailhouse
activation (L1 breakage, host seems to be fine). Loading kvm-intel with
enable_apicv=0 resolves the issue. Henning started to debug from
On 10/20/14 at 04:10pm, Michael S. Tsirkin wrote:
On Mon, Oct 20, 2014 at 01:07:50PM +0100, Thomas Graf wrote:
On 10/13/14 at 10:50am, Michael S. Tsirkin wrote:
virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after probe returns, virtio console
On Mon, Oct 20, 2014 at 04:10:16PM +0300, Michael S. Tsirkin wrote:
On Mon, Oct 20, 2014 at 01:07:50PM +0100, Thomas Graf wrote:
On 10/13/14 at 10:50am, Michael S. Tsirkin wrote:
virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after probe returns,
On Mon, Oct 20, 2014 at 02:42:23PM +0200, Cornelia Huck wrote:
On Mon, 20 Oct 2014 13:07:50 +0100
Thomas Graf tg...@suug.ch wrote:
On 10/13/14 at 10:50am, Michael S. Tsirkin wrote:
virtio spec requires drivers to set DRIVER_OK before using VQs.
This is set automatically after probe
Commit f5866db6 (virtio_console: enable VQs early) tried to make
sure that DRIVER_OK was set when virtio_console started using its
virtqueues. Doing this in add_port(), however, means that we try
to set DRIVER_OK again when when a port is dynamically added after
the probe function is done.
Let's
On Mon, Oct 20, 2014 at 04:35:55PM +0300, Michael S. Tsirkin wrote:
On Mon, Oct 20, 2014 at 02:42:23PM +0200, Cornelia Huck wrote:
On Mon, 20 Oct 2014 13:07:50 +0100
Thomas Graf tg...@suug.ch wrote:
On 10/13/14 at 10:50am, Michael S. Tsirkin wrote:
virtio spec requires drivers to
On Mon, Oct 20, 2014 at 03:58:49PM +0200, Cornelia Huck wrote:
Commit f5866db6 (virtio_console: enable VQs early) tried to make
sure that DRIVER_OK was set when virtio_console started using its
virtqueues. Doing this in add_port(), however, means that we try
to set DRIVER_OK again when when a
We switch to unlock variant with memory barriers in the error path
and also in code path where we had implicit dependency on previous
functions calling lwsync/ptesync. In most of the cases we don't really
need an explicit barrier, but using the variant make sure we don't make
mistakes later with
Minor cleanup
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
index
This patch adds helper routine for lock and unlock hpte and use
the same for rest of the code. We don't change any locking rules in this
patch. In the next patch we switch some of the unlock usage to use
the api with barrier and also document the usage without barriers.
Signed-off-by: Aneesh
On 10/20/14 at 05:04pm, Michael S. Tsirkin wrote:
Sure enough, this helps:
Tested-by: Michael S. Tsirkin m...@redhat.com
Acked-by: Michael S. Tsirkin m...@redhat.com
Pls repost as a top-level patch.
Thanks for fixing this so promptly.
--
To unsubscribe from this list: send the line
On Mon, Oct 20, 2014 at 10:05 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Oct 20, 2014 at 03:58:49PM +0200, Cornelia Huck wrote:
Commit f5866db6 (virtio_console: enable VQs early) tried to make
sure that DRIVER_OK was set when virtio_console started using its
virtqueues. Doing this
On 10/18/2014 06:28 PM, Dave Hansen wrote:
Currently it is an all or nothing thing, but for a future change we might
want to just
tag the guest memory instead of the complete user address space.
I think it's a bad idea to reserve a flag for potential future use. If
you_need_ it in the
On 10/18/2014 05:42 PM, Heinz Diehl wrote:
Sorry for being OT, but I have encountered such a situation before and
it got me into serious trouble, so I dared to share this with you.
That's actually a pretty interesting tip!
Paolo
--
To unsubscribe from this list: send the line unsubscribe
On Mon, 2014-10-13 at 15:09 +0200, Antonios Motakis wrote:
Some IOMMU drivers, such as the ARM SMMU driver, make available the
IOMMU_NOEXEC flag, to set the page tables for a device as XN (execute never).
This affects devices such as the ARM PL330 DMA Controller, which respects
this flag and
On Mon, 2014-10-13 at 15:09 +0200, Antonios Motakis wrote:
We introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag to the VFIO dma map call,
and expose its availability via the capability VFIO_DMA_NOEXEC_IOMMU.
This way the user can control whether the XN flag will be set on the
requested mappings. The
On Mon, Oct 13, 2014 at 6:09 AM, Antonios Motakis
a.mota...@virtualopensystems.com wrote:
We introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag to the VFIO dma map call,
and expose its availability via the capability VFIO_DMA_NOEXEC_IOMMU.
This way the user can control whether the XN flag will be set
Jan Kiszka wrote on 2014-10-20:
Hi all,
we just started a test with Jailhouse in a VM on a decently recent Intel
box. It has APICv / posted interrupts support. And it breaks Jailhouse
activation (L1 breakage, host seems to be fine). Loading kvm-intel with
enable_apicv=0 resolves the issue.
Dear all,
I've been given a task to add some logging capability within KVM. However, in
term of development, i have zero knowledge about KVM. Can somebody give me a
hint on good resources about KVM development?
~Ady
NAIST, Japan
--
To unsubscribe from this list: send the line
In kvm_test_clear_dirty_npages(), if we find an invalid HPTE we move on to the
next HPTE without unlocking the invalid one. In fact we should never
find an invalid and unlocked HPTE in the rmap chain, but for robustness
we should unlock it. This adds the missing unlock.
Reported-by: Benjamin
Minor cleanup
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
index
We switch to unlock variant with memory barriers in the error path
and also in code path where we had implicit dependency on previous
functions calling lwsync/ptesync. In most of the cases we don't really
need an explicit barrier, but using the variant make sure we don't make
mistakes later with
This patch adds helper routine for lock and unlock hpte and use
the same for rest of the code. We don't change any locking rules in this
patch. In the next patch we switch some of the unlock usage to use
the api with barrier and also document the usage without barriers.
Signed-off-by: Aneesh
28 matches
Mail list logo
