On Sun, Oct 11, 2015 at 12:19:54PM +0300, Michael S. Tsirkin wrote:
> > But since you must pass the same value to open(), you already know that
> > you're using noiommu.
> >
> > >VFIO_IOMMU_MAP_DMA, VFIO_IOMMU_ENABLE and VFIO_IOMMU_DISABLE
> > >will probably also fail ...
> > >
> >
> > Don't you
On Sun, Oct 11, 2015 at 12:19:54PM +0300, Michael S. Tsirkin wrote:
> > But since you must pass the same value to open(), you already know that
> > you're using noiommu.
> >
> > >VFIO_IOMMU_MAP_DMA, VFIO_IOMMU_ENABLE and VFIO_IOMMU_DISABLE
> > >will probably also fail ...
> > >
> >
> > Don't you
On Thu, Oct 08, 2015 at 08:39:10PM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 08:01:21PM +0300, Gleb Natapov wrote:
> > On Thu, Oct 08, 2015 at 07:43:04PM +0300, Michael S. Tsirkin wrote:
> > > On Thu, Oct 08, 2015 at 04:28:34PM +0300, Gleb Natapov wrote:
>
On Thu, Oct 08, 2015 at 07:43:04PM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 04:28:34PM +0300, Gleb Natapov wrote:
> > On Thu, Oct 08, 2015 at 04:20:04PM +0300, Michael S. Tsirkin wrote:
> > > On Thu, Oct 08, 2015 at 03:27:37PM +0300, Gleb Natapov wrote:
>
On Thu, Oct 08, 2015 at 04:20:04PM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 03:27:37PM +0300, Gleb Natapov wrote:
> > On Thu, Oct 08, 2015 at 03:06:07PM +0300, Michael S. Tsirkin wrote:
> > > On Thu, Oct 08, 2015 at 12:44:09PM +0300
On Thu, Oct 08, 2015 at 03:06:07PM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 12:44:09PM +0300, Avi Kivity wrote:
> >
> >
> > On 10/08/2015 12:16 PM, Michael S. Tsirkin wrote:
> > >On Thu, Oct 08, 2015 at 11:46:30AM +0300, Avi Kivity wrote:
> > >>
> > >>On 10/08/2015 10:32 AM,
On Thu, Oct 08, 2015 at 12:38:28PM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 10:59:10AM +0300, Gleb Natapov wrote:
> > I do not remember this been an issue when uio_generic was accepted
> > into the kernel. The reason was because it meant to be accessible b
On Thu, Oct 08, 2015 at 11:32:50AM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 08:33:45AM +0300, Avi Kivity wrote:
> > On 08/10/15 00:05, Michael S. Tsirkin wrote:
> > >On Wed, Oct 07, 2015 at 07:39:16PM +0300, Avi Kivity wrote:
> > >>That's what I thought as well, but apparently
On Thu, Oct 08, 2015 at 10:41:53AM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 07:19:13AM +0300, Gleb Natapov wrote:
> > Well
> > the alternative is to add /dev/vfio/nommu like you've said, but what
> > would be the difference between this and uio eludes me.
On Thu, Oct 08, 2015 at 11:32:50AM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 08:33:45AM +0300, Avi Kivity wrote:
> > On 08/10/15 00:05, Michael S. Tsirkin wrote:
> > >On Wed, Oct 07, 2015 at 07:39:16PM +0300, Avi Kivity wrote:
> > >>That's what I thought as well, but apparently
On Thu, Oct 08, 2015 at 10:41:53AM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 07:19:13AM +0300, Gleb Natapov wrote:
> > Well
> > the alternative is to add /dev/vfio/nommu like you've said, but what
> > would be the difference between this and uio eludes me.
On Thu, Oct 08, 2015 at 12:38:28PM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 10:59:10AM +0300, Gleb Natapov wrote:
> > I do not remember this been an issue when uio_generic was accepted
> > into the kernel. The reason was because it meant to be accessible b
On Thu, Oct 08, 2015 at 03:06:07PM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 12:44:09PM +0300, Avi Kivity wrote:
> >
> >
> > On 10/08/2015 12:16 PM, Michael S. Tsirkin wrote:
> > >On Thu, Oct 08, 2015 at 11:46:30AM +0300, Avi Kivity wrote:
> > >>
> > >>On 10/08/2015 10:32 AM,
On Thu, Oct 08, 2015 at 04:20:04PM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 03:27:37PM +0300, Gleb Natapov wrote:
> > On Thu, Oct 08, 2015 at 03:06:07PM +0300, Michael S. Tsirkin wrote:
> > > On Thu, Oct 08, 2015 at 12:44:09PM +0300
On Thu, Oct 08, 2015 at 07:43:04PM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 04:28:34PM +0300, Gleb Natapov wrote:
> > On Thu, Oct 08, 2015 at 04:20:04PM +0300, Michael S. Tsirkin wrote:
> > > On Thu, Oct 08, 2015 at 03:27:37PM +0300, Gleb Natapov wrote:
>
On Thu, Oct 08, 2015 at 08:39:10PM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 08, 2015 at 08:01:21PM +0300, Gleb Natapov wrote:
> > On Thu, Oct 08, 2015 at 07:43:04PM +0300, Michael S. Tsirkin wrote:
> > > On Thu, Oct 08, 2015 at 04:28:34PM +0300, Gleb Natapov wrote:
>
On Thu, Oct 08, 2015 at 12:05:11AM +0300, Michael S. Tsirkin wrote:
> On Wed, Oct 07, 2015 at 07:39:16PM +0300, Avi Kivity wrote:
> > That's what I thought as well, but apparently adding msix support to the
> > already insecure uio drivers is even worse.
>
> I'm glad you finally agree what these
On Thu, Oct 08, 2015 at 12:05:11AM +0300, Michael S. Tsirkin wrote:
> On Wed, Oct 07, 2015 at 07:39:16PM +0300, Avi Kivity wrote:
> > That's what I thought as well, but apparently adding msix support to the
> > already insecure uio drivers is even worse.
>
> I'm glad you finally agree what these
On Tue, Oct 06, 2015 at 06:15:54PM +0300, Michael S. Tsirkin wrote:
> > While it is possible that userspace malfunctions and accidentally programs
> > MSI incorrectly, the risk is dwarfed by the ability of userspace to program
> > DMA incorrectly.
>
> That seems to imply that for the upstream
On Tue, Oct 06, 2015 at 06:19:34PM +0300, Michael S. Tsirkin wrote:
> On Tue, Oct 06, 2015 at 05:30:31PM +0300, Gleb Natapov wrote:
> > On Tue, Oct 06, 2015 at 05:19:22PM +0300, Michael S. Tsirkin wrote:
> > > On Tue, Oct 06, 2015 at 11:33:56AM +0300, Vlad Zolotarov wrote:
>
On Tue, Oct 06, 2015 at 05:19:22PM +0300, Michael S. Tsirkin wrote:
> On Tue, Oct 06, 2015 at 11:33:56AM +0300, Vlad Zolotarov wrote:
> > the solution u propose should be a matter of a separate patch and is
> > obviously orthogonal to this series.
>
> Doesn't work this way, sorry. You want a
On Tue, Oct 06, 2015 at 05:19:22PM +0300, Michael S. Tsirkin wrote:
> On Tue, Oct 06, 2015 at 11:33:56AM +0300, Vlad Zolotarov wrote:
> > the solution u propose should be a matter of a separate patch and is
> > obviously orthogonal to this series.
>
> Doesn't work this way, sorry. You want a
On Tue, Oct 06, 2015 at 06:19:34PM +0300, Michael S. Tsirkin wrote:
> On Tue, Oct 06, 2015 at 05:30:31PM +0300, Gleb Natapov wrote:
> > On Tue, Oct 06, 2015 at 05:19:22PM +0300, Michael S. Tsirkin wrote:
> > > On Tue, Oct 06, 2015 at 11:33:56AM +0300, Vlad Zolotarov wrote:
>
On Tue, Oct 06, 2015 at 06:15:54PM +0300, Michael S. Tsirkin wrote:
> > While it is possible that userspace malfunctions and accidentally programs
> > MSI incorrectly, the risk is dwarfed by the ability of userspace to program
> > DMA incorrectly.
>
> That seems to imply that for the upstream
On Wed, Nov 19, 2014 at 10:05:43PM +0100, Paolo Bonzini wrote:
> KVM for ia64 has been marked as broken not just once, but twice even,
> and the last patch from the maintainer is now roughly 5 years old.
> Time for it to rest in piece.
>
Acked-by: Gleb Natapov
Next step is to move
On Wed, Nov 19, 2014 at 10:05:43PM +0100, Paolo Bonzini wrote:
KVM for ia64 has been marked as broken not just once, but twice even,
and the last patch from the maintainer is now roughly 5 years old.
Time for it to rest in piece.
Acked-by: Gleb Natapov g...@kernel.org
Next step is to move
On Mon, Sep 22, 2014 at 09:29:19PM +0200, Paolo Bonzini wrote:
> Il 22/09/2014 21:20, Christian Borntraeger ha scritto:
> > "while using trinity to fuzz KVM, we noticed long stalls on invalid ioctls.
> > Lets bail out early on invalid ioctls". or similar?
>
> Okay. David, can you explain how
On Mon, Sep 22, 2014 at 09:29:19PM +0200, Paolo Bonzini wrote:
Il 22/09/2014 21:20, Christian Borntraeger ha scritto:
while using trinity to fuzz KVM, we noticed long stalls on invalid ioctls.
Lets bail out early on invalid ioctls. or similar?
Okay. David, can you explain how you found
e relinquished in the case
> of IO wait.
>
Reviewed-by: Gleb Natapov
> Reviewed-by: Radim Krčmář
> Signed-off-by: Andres Lagar-Cavilla
>
> ---
> v1 -> v2
>
> * WARN_ON_ONCE -> VM_WARN_ON_ONCE
> * pagep == NULL skips the final retry
> * kvm_gu
On Thu, Sep 18, 2014 at 08:29:17AM +0800, Wanpeng Li wrote:
> Hi Andres,
> On Wed, Sep 17, 2014 at 10:51:48AM -0700, Andres Lagar-Cavilla wrote:
> [...]
> > static inline int check_user_page_hwpoison(unsigned long addr)
> > {
> > int rc, flags = FOLL_TOUCH | FOLL_HWPOISON | FOLL_WRITE;
> >@@
On Thu, Sep 18, 2014 at 08:29:17AM +0800, Wanpeng Li wrote:
Hi Andres,
On Wed, Sep 17, 2014 at 10:51:48AM -0700, Andres Lagar-Cavilla wrote:
[...]
static inline int check_user_page_hwpoison(unsigned long addr)
{
int rc, flags = FOLL_TOUCH | FOLL_HWPOISON | FOLL_WRITE;
@@ -1177,9
on the IO. This is a bad thing, as other mmap semaphore users
now stall as a function of swap or filemap latency.
This patch ensures both the regular and async PF path re-enter the
fault allowing for the mmap semaphore to be relinquished in the case
of IO wait.
Reviewed-by: Gleb Natapov g
On Wed, Sep 17, 2014 at 10:13:45AM -0700, Andres Lagar-Cavilla wrote:
> On Wed, Sep 17, 2014 at 10:08 AM, Gleb Natapov wrote:
> > On Wed, Sep 17, 2014 at 10:00:32AM -0700, Andres Lagar-Cavilla wrote:
> >> On Wed, Sep 17, 2014 at 4:42 AM, Gleb Natapov wrote:
> >> >
On Wed, Sep 17, 2014 at 10:00:32AM -0700, Andres Lagar-Cavilla wrote:
> On Wed, Sep 17, 2014 at 4:42 AM, Gleb Natapov wrote:
> > On Wed, Sep 17, 2014 at 01:27:14PM +0200, Radim Krčmář wrote:
> >> 2014-09-17 13:26+0300, Gleb Natapov:
> >> > For async_pf_execute()
On Wed, Sep 17, 2014 at 01:27:14PM +0200, Radim Krčmář wrote:
> 2014-09-17 13:26+0300, Gleb Natapov:
> > For async_pf_execute() you do not need to even retry. Next guest's page
> > fault
> > will retry it for you.
>
> Wouldn't that be a waste of vmentrie
On Mon, Sep 15, 2014 at 01:11:25PM -0700, Andres Lagar-Cavilla wrote:
> When KVM handles a tdp fault it uses FOLL_NOWAIT. If the guest memory has been
> swapped out or is behind a filemap, this will trigger async readahead and
> return immediately. The rationale is that KVM will kick back the
On Mon, Sep 15, 2014 at 01:11:25PM -0700, Andres Lagar-Cavilla wrote:
When KVM handles a tdp fault it uses FOLL_NOWAIT. If the guest memory has been
swapped out or is behind a filemap, this will trigger async readahead and
return immediately. The rationale is that KVM will kick back the guest
On Wed, Sep 17, 2014 at 01:27:14PM +0200, Radim Krčmář wrote:
2014-09-17 13:26+0300, Gleb Natapov:
For async_pf_execute() you do not need to even retry. Next guest's page
fault
will retry it for you.
Wouldn't that be a waste of vmentries?
This is how it will work with or without
On Wed, Sep 17, 2014 at 10:00:32AM -0700, Andres Lagar-Cavilla wrote:
On Wed, Sep 17, 2014 at 4:42 AM, Gleb Natapov g...@kernel.org wrote:
On Wed, Sep 17, 2014 at 01:27:14PM +0200, Radim Krčmář wrote:
2014-09-17 13:26+0300, Gleb Natapov:
For async_pf_execute() you do not need to even retry
On Wed, Sep 17, 2014 at 10:13:45AM -0700, Andres Lagar-Cavilla wrote:
On Wed, Sep 17, 2014 at 10:08 AM, Gleb Natapov g...@kernel.org wrote:
On Wed, Sep 17, 2014 at 10:00:32AM -0700, Andres Lagar-Cavilla wrote:
On Wed, Sep 17, 2014 at 4:42 AM, Gleb Natapov g...@kernel.org wrote:
On Wed, Sep
On Thu, Sep 11, 2014 at 04:37:39PM +0200, Paolo Bonzini wrote:
> Il 11/09/2014 16:31, Gleb Natapov ha scritto:
> >> > What if the page being swapped out is L1's APIC access page? We don't
> >> > run prepare_vmcs12 in that case because it's an L2->L0->L2 entry, s
On Thu, Sep 11, 2014 at 04:24:04PM +0200, Paolo Bonzini wrote:
> Il 11/09/2014 16:21, Gleb Natapov ha scritto:
> > As far as I can tell the if that is needed there is:
> >
> > if (!is_guest_mode() || !(vmcs12->secondary_vm_exec_control &
> > ECONDARY_EXEC_VIRTUA
On Thu, Sep 11, 2014 at 04:06:58PM +0200, Paolo Bonzini wrote:
> Il 11/09/2014 15:59, Gleb Natapov ha scritto:
> >
> > Suppose vmcs01->APIC_ACCESS_ADDR = 0xf000. During L2 entry
> > vmcs02->APIC_ACCESS_ADDR is set to 0xf000 too (by prepare_vmcs02). Now
> >
On Thu, Sep 11, 2014 at 03:05:05PM +0200, Paolo Bonzini wrote:
> Il 11/09/2014 13:30, Gleb Natapov ha scritto:
> >> > +vmcs_write64(APIC_ACCESS_ADDR,
> >> > page_to_phys(page));
> >> > +/*
> >> >
On Thu, Sep 11, 2014 at 12:47:16PM +0200, Paolo Bonzini wrote:
> Il 11/09/2014 12:12, Gleb Natapov ha scritto:
> > On Thu, Sep 11, 2014 at 11:21:49AM +0200, Paolo Bonzini wrote:
> >> Il 11/09/2014 07:38, Tang Chen ha scritto:
> >>> diff --git a/arch/x86/kvm/vmx.c b/
On Thu, Sep 11, 2014 at 11:21:49AM +0200, Paolo Bonzini wrote:
> Il 11/09/2014 07:38, Tang Chen ha scritto:
> > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > index 63c4c3e..da6d55d 100644
> > --- a/arch/x86/kvm/vmx.c
> > +++ b/arch/x86/kvm/vmx.c
> > @@ -7093,6 +7093,11 @@ static void
On Thu, Sep 11, 2014 at 11:21:49AM +0200, Paolo Bonzini wrote:
Il 11/09/2014 07:38, Tang Chen ha scritto:
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 63c4c3e..da6d55d 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -7093,6 +7093,11 @@ static void
On Thu, Sep 11, 2014 at 12:47:16PM +0200, Paolo Bonzini wrote:
Il 11/09/2014 12:12, Gleb Natapov ha scritto:
On Thu, Sep 11, 2014 at 11:21:49AM +0200, Paolo Bonzini wrote:
Il 11/09/2014 07:38, Tang Chen ha scritto:
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 63c4c3e
On Thu, Sep 11, 2014 at 03:05:05PM +0200, Paolo Bonzini wrote:
Il 11/09/2014 13:30, Gleb Natapov ha scritto:
+vmcs_write64(APIC_ACCESS_ADDR,
page_to_phys(page));
+/*
+ * Do not pin apic access page in memory so
On Thu, Sep 11, 2014 at 04:06:58PM +0200, Paolo Bonzini wrote:
Il 11/09/2014 15:59, Gleb Natapov ha scritto:
Suppose vmcs01-APIC_ACCESS_ADDR = 0xf000. During L2 entry
vmcs02-APIC_ACCESS_ADDR is set to 0xf000 too (by prepare_vmcs02). Now
0xf000 is migrated to 0x8000, mmu notifier
On Thu, Sep 11, 2014 at 04:24:04PM +0200, Paolo Bonzini wrote:
Il 11/09/2014 16:21, Gleb Natapov ha scritto:
As far as I can tell the if that is needed there is:
if (!is_guest_mode() || !(vmcs12-secondary_vm_exec_control
ECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES))
write
On Thu, Sep 11, 2014 at 04:37:39PM +0200, Paolo Bonzini wrote:
Il 11/09/2014 16:31, Gleb Natapov ha scritto:
What if the page being swapped out is L1's APIC access page? We don't
run prepare_vmcs12 in that case because it's an L2-L0-L2 entry, so we
need to do something.
We will do
On Tue, Sep 09, 2014 at 03:13:07PM +0800, tangchen wrote:
> Hi Gleb,
>
> On 09/03/2014 11:04 PM, Gleb Natapov wrote:
> >On Wed, Sep 03, 2014 at 09:42:30AM +0800, tangchen wrote:
> >>Hi Gleb,
> >>
> >>On 09/03/2014 12:00 AM, Gleb Na
tity pagetable page is pinned in memroy.
> As a result, it cannot be migrated/hot-removed. After this patch, since
> kvm_arch->ept_identity_pagetable is removed, ept identity pagetable page
> is no longer pinned in memory. And it can be migrated/hot-removed.
Reviewed-by: Gleb Natapov
On Wed, Aug 27, 2014 at 06:17:36PM +0800, Tang Chen wrote:
> We have APIC_DEFAULT_PHYS_BASE defined as 0xfee0, which is also the
> address of
> apic access page. So use this macro.
Reviewed-by: Gleb Natapov
>
> Signed-off-by: Tang Chen
> ---
> arch/x86/kvm/svm.c |
On Wed, Aug 27, 2014 at 06:17:36PM +0800, Tang Chen wrote:
We have APIC_DEFAULT_PHYS_BASE defined as 0xfee0, which is also the
address of
apic access page. So use this macro.
Reviewed-by: Gleb Natapov g...@kernel.org
Signed-off-by: Tang Chen tangc...@cn.fujitsu.com
---
arch/x86/kvm
, it cannot be migrated/hot-removed. After this patch, since
kvm_arch-ept_identity_pagetable is removed, ept identity pagetable page
is no longer pinned in memory. And it can be migrated/hot-removed.
Reviewed-by: Gleb Natapov g...@kernel.org
Signed-off-by: Tang Chen tangc
On Tue, Sep 09, 2014 at 03:13:07PM +0800, tangchen wrote:
Hi Gleb,
On 09/03/2014 11:04 PM, Gleb Natapov wrote:
On Wed, Sep 03, 2014 at 09:42:30AM +0800, tangchen wrote:
Hi Gleb,
On 09/03/2014 12:00 AM, Gleb Natapov wrote:
..
+static void vcpu_reload_apic_access_page(struct kvm_vcpu
On Thu, Sep 04, 2014 at 07:44:51PM +0200, Paolo Bonzini wrote:
> Il 04/09/2014 17:05, Gleb Natapov ha scritto:
> >> >
> >> > If you do that, KVM gets down to the "if (writeback)" and writes the
> >> > ctxt->eip from L2 into the L1 EIP
On Thu, Sep 04, 2014 at 07:44:51PM +0200, Paolo Bonzini wrote:
Il 04/09/2014 17:05, Gleb Natapov ha scritto:
If you do that, KVM gets down to the if (writeback) and writes the
ctxt-eip from L2 into the L1 EIP.
Heh, that's a bummer. We should not write back if an instruction caused
On Thu, Sep 04, 2014 at 04:12:19PM +0200, Paolo Bonzini wrote:
> Il 04/09/2014 09:02, Gleb Natapov ha scritto:
> > On Tue, Sep 02, 2014 at 05:13:49PM +0200, Paolo Bonzini wrote:
> >> > This is required for the following patch to work correctly. If a nested
> >> >
On Tue, Sep 02, 2014 at 05:13:49PM +0200, Paolo Bonzini wrote:
> This is required for the following patch to work correctly. If a nested page
> fault happens during emulation, we must inject a vmexit, not a page fault.
> Luckily we already have the required machinery: it is enough to return
>
On Tue, Sep 02, 2014 at 05:13:49PM +0200, Paolo Bonzini wrote:
This is required for the following patch to work correctly. If a nested page
fault happens during emulation, we must inject a vmexit, not a page fault.
Luckily we already have the required machinery: it is enough to return
On Thu, Sep 04, 2014 at 04:12:19PM +0200, Paolo Bonzini wrote:
Il 04/09/2014 09:02, Gleb Natapov ha scritto:
On Tue, Sep 02, 2014 at 05:13:49PM +0200, Paolo Bonzini wrote:
This is required for the following patch to work correctly. If a nested
page
fault happens during emulation, we
On Wed, Sep 03, 2014 at 09:42:30AM +0800, tangchen wrote:
> Hi Gleb,
>
> On 09/03/2014 12:00 AM, Gleb Natapov wrote:
> >..
> >+static void vcpu_reload_apic_access_page(struct kvm_vcpu *vcpu)
> >+{
> >+/*
> >+ * apic access page could be mi
On Wed, Aug 27, 2014 at 06:17:40PM +0800, Tang Chen wrote:
> This patch only handle "L1 and L2 vm share one apic access page" situation.
>
> When L1 vm is running, if the shared apic access page is migrated,
> mmu_notifier will
> request all vcpus to exit to L0, and reload apic access page
On Wed, Aug 27, 2014 at 06:17:40PM +0800, Tang Chen wrote:
This patch only handle L1 and L2 vm share one apic access page situation.
When L1 vm is running, if the shared apic access page is migrated,
mmu_notifier will
request all vcpus to exit to L0, and reload apic access page physical
On Wed, Sep 03, 2014 at 09:42:30AM +0800, tangchen wrote:
Hi Gleb,
On 09/03/2014 12:00 AM, Gleb Natapov wrote:
..
+static void vcpu_reload_apic_access_page(struct kvm_vcpu *vcpu)
+{
+/*
+ * apic access page could be migrated. When the page is being migrated,
+ * GUP
On Wed, Aug 27, 2014 at 06:17:39PM +0800, Tang Chen wrote:
> apic access page is pinned in memory. As a result, it cannot be
> migrated/hot-removed.
> Actually, it is not necessary to be pinned.
>
> The hpa of apic access page is stored in VMCS APIC_ACCESS_ADDR pointer. When
> the page is
On Wed, Aug 27, 2014 at 06:17:39PM +0800, Tang Chen wrote:
apic access page is pinned in memory. As a result, it cannot be
migrated/hot-removed.
Actually, it is not necessary to be pinned.
The hpa of apic access page is stored in VMCS APIC_ACCESS_ADDR pointer. When
the page is migrated,
On Tue, Aug 26, 2014 at 04:58:34PM -0700, Andy Lutomirski wrote:
> hpa pointed out that the ABI that I chose (an MSR from the KVM range
> and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice
> to allocate an MSR that everyone involved can agree on and, rather
> than relying on a
On Tue, Aug 26, 2014 at 04:58:34PM -0700, Andy Lutomirski wrote:
hpa pointed out that the ABI that I chose (an MSR from the KVM range
and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice
to allocate an MSR that everyone involved can agree on and, rather
than relying on a cpuid
On Mon, Aug 25, 2014 at 11:16:34AM +0800, Dennis Chen wrote:
> On Sun, Aug 24, 2014 at 5:38 PM, Gleb Natapov wrote:
> > On Sun, Aug 24, 2014 at 11:54:32AM +0800, Dennis Chen wrote:
> >> This patch is used to construct the eptp in vmx mode with values
> >> readed from
On Mon, Aug 25, 2014 at 11:16:34AM +0800, Dennis Chen wrote:
On Sun, Aug 24, 2014 at 5:38 PM, Gleb Natapov g...@kernel.org wrote:
On Sun, Aug 24, 2014 at 11:54:32AM +0800, Dennis Chen wrote:
This patch is used to construct the eptp in vmx mode with values
readed from MSR according
On Sun, Aug 24, 2014 at 11:54:32AM +0800, Dennis Chen wrote:
> This patch is used to construct the eptp in vmx mode with values
> readed from MSR according to the intel x86 software developer's
> manual.
>
> Signed-off-by: Dennis Chen
> ---
> arch/x86/include/asm/vmx.h |1 +
>
On Sun, Aug 24, 2014 at 11:54:32AM +0800, Dennis Chen wrote:
This patch is used to construct the eptp in vmx mode with values
readed from MSR according to the intel x86 software developer's
manual.
Signed-off-by: Dennis Chen kernel.org@gmail.com
---
arch/x86/include/asm/vmx.h |1 +
On Fri, Jul 18, 2014 at 05:05:20PM +0800, Tang Chen wrote:
> Hi Gleb,
>
> On 07/17/2014 09:57 PM, Gleb Natapov wrote:
> >On Thu, Jul 17, 2014 at 09:34:20PM +0800, Tang Chen wrote:
> >>Hi Gleb,
> >>
> >>On 07/15/2014 08:40 PM, Gleb Natapov wrote
On Fri, Jul 18, 2014 at 05:05:20PM +0800, Tang Chen wrote:
Hi Gleb,
On 07/17/2014 09:57 PM, Gleb Natapov wrote:
On Thu, Jul 17, 2014 at 09:34:20PM +0800, Tang Chen wrote:
Hi Gleb,
On 07/15/2014 08:40 PM, Gleb Natapov wrote:
..
And yes, we have the problem you said here. We can
On Thu, Jul 17, 2014 at 09:34:20PM +0800, Tang Chen wrote:
> Hi Gleb,
>
> On 07/15/2014 08:40 PM, Gleb Natapov wrote:
> ..
> >>
> >>And yes, we have the problem you said here. We can migrate the page while L2
> >>vm is running.
> >>So I th
On Thu, Jul 17, 2014 at 09:34:20PM +0800, Tang Chen wrote:
Hi Gleb,
On 07/15/2014 08:40 PM, Gleb Natapov wrote:
..
And yes, we have the problem you said here. We can migrate the page while L2
vm is running.
So I think we should enforce L2 vm to exit to L1. Right ?
We can request
On Wed, Jul 16, 2014 at 09:13:23AM -0700, H. Peter Anvin wrote:
> On 07/16/2014 09:08 AM, Paolo Bonzini wrote:
> > Il 16/07/2014 18:03, H. Peter Anvin ha scritto:
> >> I suggested emulating RDRAND *but not set the CPUID bit*. We already
> >> developed a protocol in KVM/Qemu to enumerate emulated
On Wed, Jul 16, 2014 at 04:32:19PM +0200, Paolo Bonzini wrote:
> Il 16/07/2014 16:07, Andy Lutomirski ha scritto:
> >This patch has nothing whatsoever to do with how much I trust the CPU
> >vs the hypervisor. It's for the enormous installed base of machines
> >without RDRAND.
>
> Ok. I think an
On Wed, Jul 16, 2014 at 09:10:27AM +0200, Daniel Borkmann wrote:
> On 07/16/2014 08:41 AM, Gleb Natapov wrote:
> >On Tue, Jul 15, 2014 at 07:48:06PM -0700, Andy Lutomirski wrote:
> >>virtio-rng is both too complicated and insufficient for initial rng
> >>seeding. It's
On Tue, Jul 15, 2014 at 07:48:06PM -0700, Andy Lutomirski wrote:
> virtio-rng is both too complicated and insufficient for initial rng
> seeding. It's far too complicated to use for KASLR or any other
> early boot random number needs. It also provides /dev/random-style
> bits, which means that
On Tue, Jul 15, 2014 at 07:48:06PM -0700, Andy Lutomirski wrote:
virtio-rng is both too complicated and insufficient for initial rng
seeding. It's far too complicated to use for KASLR or any other
early boot random number needs. It also provides /dev/random-style
bits, which means that
On Wed, Jul 16, 2014 at 09:10:27AM +0200, Daniel Borkmann wrote:
On 07/16/2014 08:41 AM, Gleb Natapov wrote:
On Tue, Jul 15, 2014 at 07:48:06PM -0700, Andy Lutomirski wrote:
virtio-rng is both too complicated and insufficient for initial rng
seeding. It's far too complicated to use for KASLR
On Wed, Jul 16, 2014 at 04:32:19PM +0200, Paolo Bonzini wrote:
Il 16/07/2014 16:07, Andy Lutomirski ha scritto:
This patch has nothing whatsoever to do with how much I trust the CPU
vs the hypervisor. It's for the enormous installed base of machines
without RDRAND.
Ok. I think an MSR is
On Wed, Jul 16, 2014 at 09:13:23AM -0700, H. Peter Anvin wrote:
On 07/16/2014 09:08 AM, Paolo Bonzini wrote:
Il 16/07/2014 18:03, H. Peter Anvin ha scritto:
I suggested emulating RDRAND *but not set the CPUID bit*. We already
developed a protocol in KVM/Qemu to enumerate emulated features
On Tue, Jul 15, 2014 at 08:54:01PM +0800, Tang Chen wrote:
> On 07/15/2014 08:40 PM, Gleb Natapov wrote:
> >On Tue, Jul 15, 2014 at 08:28:22PM +0800, Tang Chen wrote:
> >>On 07/15/2014 08:09 PM, Gleb Natapov wrote:
> >>>On Tue, Jul 15, 2014 at 01:5
On Tue, Jul 15, 2014 at 03:10:15PM +0200, Jan Kiszka wrote:
> On 2014-07-15 14:40, Gleb Natapov wrote:
> >>
> >> ..
> >> 7922 if (!vmx->nested.apic_access_page)
> >> 7923 exec_control &=
>
On Tue, Jul 15, 2014 at 08:28:22PM +0800, Tang Chen wrote:
> On 07/15/2014 08:09 PM, Gleb Natapov wrote:
> >On Tue, Jul 15, 2014 at 01:52:40PM +0200, Jan Kiszka wrote:
> ..
> >>
> >>I cannot follow your concerns yet. Specifically, how should
> >>APIC_ACCE
On Tue, Jul 15, 2014 at 01:52:40PM +0200, Jan Kiszka wrote:
> On 2014-07-14 16:58, Gleb Natapov wrote:
> >>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> >>>> index ffbe557..7080eda 100644
> >>>> --- a/arch/x86/kvm/x86.c
> >&
On Tue, Jul 15, 2014 at 01:52:40PM +0200, Jan Kiszka wrote:
On 2014-07-14 16:58, Gleb Natapov wrote:
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ffbe557..7080eda 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5929,6 +5929,18 @@ static void vcpu_scan_ioapic
On Tue, Jul 15, 2014 at 08:28:22PM +0800, Tang Chen wrote:
On 07/15/2014 08:09 PM, Gleb Natapov wrote:
On Tue, Jul 15, 2014 at 01:52:40PM +0200, Jan Kiszka wrote:
..
I cannot follow your concerns yet. Specifically, how should
APIC_ACCESS_ADDR (the VMCS field, right?) change while L2
On Tue, Jul 15, 2014 at 03:10:15PM +0200, Jan Kiszka wrote:
On 2014-07-15 14:40, Gleb Natapov wrote:
..
7922 if (!vmx-nested.apic_access_page)
7923 exec_control =
7924 ~SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
7925
On Tue, Jul 15, 2014 at 08:54:01PM +0800, Tang Chen wrote:
On 07/15/2014 08:40 PM, Gleb Natapov wrote:
On Tue, Jul 15, 2014 at 08:28:22PM +0800, Tang Chen wrote:
On 07/15/2014 08:09 PM, Gleb Natapov wrote:
On Tue, Jul 15, 2014 at 01:52:40PM +0200, Jan Kiszka wrote:
..
I cannot follow
CCing Jan to check my nested kvm findings below.
On Mon, Jul 14, 2014 at 03:57:09PM +0800, Tang Chen wrote:
> Hi Gleb,
>
> Thanks for the reply. Please see below.
>
> On 07/12/2014 04:04 PM, Gleb Natapov wrote:
> >On Tue, Jul 08, 2014 at 09:01:32PM +0800, Tang Chen wrote:
On Mon, Jul 14, 2014 at 05:17:04PM +0800, Tang Chen wrote:
> On 07/12/2014 03:44 PM, Gleb Natapov wrote:
> >On Wed, Jul 09, 2014 at 10:08:03AM +0800, Tang Chen wrote:
> >>kvm_arch->ept_identity_pagetable holds the ept identity pagetable page. But
> >>it is never us
On Mon, Jul 14, 2014 at 05:17:04PM +0800, Tang Chen wrote:
On 07/12/2014 03:44 PM, Gleb Natapov wrote:
On Wed, Jul 09, 2014 at 10:08:03AM +0800, Tang Chen wrote:
kvm_arch-ept_identity_pagetable holds the ept identity pagetable page. But
it is never used to refer to the page at all.
In vcpu
CCing Jan to check my nested kvm findings below.
On Mon, Jul 14, 2014 at 03:57:09PM +0800, Tang Chen wrote:
Hi Gleb,
Thanks for the reply. Please see below.
On 07/12/2014 04:04 PM, Gleb Natapov wrote:
On Tue, Jul 08, 2014 at 09:01:32PM +0800, Tang Chen wrote:
apic access page is pinned
1 - 100 of 1410 matches
Mail list logo
