On Fri, Feb 28, 2014 at 12:52:53PM +0100, Andrew Jones wrote:
> This patch series addresses two issues with global clock updates.
> The first fixes a bug found on hosts that have a tsc marked as
> unstable. As global clock updates get triggered on every vcpu load
> in these cases, guests with a
On Fri, Feb 28, 2014 at 12:52:53PM +0100, Andrew Jones wrote:
This patch series addresses two issues with global clock updates.
The first fixes a bug found on hosts that have a tsc marked as
unstable. As global clock updates get triggered on every vcpu load
in these cases, guests with a large
On Wed, Feb 26, 2014 at 07:15:11PM +0100, Andrew Jones wrote:
> When we update a vcpu's local clock it may pick up an NTP correction.
> We can't wait an indeterminate amount of time for other vcpus to pick
> up that correction, so commit 0061d53daf26f introduced a global clock
> update. However,
On Wed, Feb 26, 2014 at 07:15:12PM +0100, Andrew Jones wrote:
> commit 0061d53daf26f introduced a mechanism to execute a global clock
> update for a vm. We can apply this periodically in order to propagate
> host NTP corrections. Also, if all vcpus of a vm are pinned, then
> without an additional
On Wed, Feb 26, 2014 at 07:15:12PM +0100, Andrew Jones wrote:
commit 0061d53daf26f introduced a mechanism to execute a global clock
update for a vm. We can apply this periodically in order to propagate
host NTP corrections. Also, if all vcpus of a vm are pinned, then
without an additional
On Wed, Feb 26, 2014 at 07:15:11PM +0100, Andrew Jones wrote:
When we update a vcpu's local clock it may pick up an NTP correction.
We can't wait an indeterminate amount of time for other vcpus to pick
up that correction, so commit 0061d53daf26f introduced a global clock
update. However, we
On Mon, Feb 24, 2014 at 04:42:29PM +0100, Andrew Jones wrote:
> When the tsc is marked unstable on the host it causes global clock
> updates to be requested each time a vcpu is loaded, nearly halting
> all progress on guests with a large number of vcpus.
>
> Fix this by only requesting a local
On Mon, Feb 24, 2014 at 04:42:29PM +0100, Andrew Jones wrote:
When the tsc is marked unstable on the host it causes global clock
updates to be requested each time a vcpu is loaded, nearly halting
all progress on guests with a large number of vcpus.
Fix this by only requesting a local clock
On Fri, Feb 21, 2014 at 02:07:08AM -0800, David Rientjes wrote:
> On Thu, 20 Feb 2014, Marcelo Tosatti wrote:
>
> > > 1GB is of such granularity that you'd typically either be (a) oom so that
> > > your userspace couldn't even start, or (b) have enough memory such tha
On Fri, Feb 21, 2014 at 02:07:08AM -0800, David Rientjes wrote:
On Thu, 20 Feb 2014, Marcelo Tosatti wrote:
1GB is of such granularity that you'd typically either be (a) oom so that
your userspace couldn't even start, or (b) have enough memory such that
userspace would be able
On Thu, Feb 20, 2014 at 03:15:46PM -0800, David Rientjes wrote:
> On Thu, 20 Feb 2014, Marcelo Tosatti wrote:
>
> > Mel has clearly has no objection to the command line. You can also
> > allocate 2M pages at runtime, and that is no reason for "hugepages="
On Wed, Feb 19, 2014 at 07:46:41PM -0800, David Rientjes wrote:
> On Wed, 19 Feb 2014, Marcelo Tosatti wrote:
>
> > We agree that, in the future, we'd like to provide the ability to
> > dynamically allocate and free 1GB pages at runtime.
> >
> > Extending the
On Wed, Feb 19, 2014 at 07:46:41PM -0800, David Rientjes wrote:
> On Wed, 19 Feb 2014, Marcelo Tosatti wrote:
>
> > We agree that, in the future, we'd like to provide the ability to
> > dynamically allocate and free 1GB pages at runtime.
> >
> > Extending the
On Wed, Feb 19, 2014 at 07:46:41PM -0800, David Rientjes wrote:
On Wed, 19 Feb 2014, Marcelo Tosatti wrote:
We agree that, in the future, we'd like to provide the ability to
dynamically allocate and free 1GB pages at runtime.
Extending the kernel command line interface is a first step
On Wed, Feb 19, 2014 at 07:46:41PM -0800, David Rientjes wrote:
On Wed, 19 Feb 2014, Marcelo Tosatti wrote:
We agree that, in the future, we'd like to provide the ability to
dynamically allocate and free 1GB pages at runtime.
Extending the kernel command line interface is a first step
On Thu, Feb 20, 2014 at 03:15:46PM -0800, David Rientjes wrote:
On Thu, 20 Feb 2014, Marcelo Tosatti wrote:
Mel has clearly has no objection to the command line. You can also
allocate 2M pages at runtime, and that is no reason for hugepages=
interface to not exist.
The hugepages
On Tue, Feb 18, 2014 at 02:16:42PM -0800, David Rientjes wrote:
> On Tue, 18 Feb 2014, Marcelo Tosatti wrote:
>
> > > Lacking from your entire patchset is a specific example of what you want
> > > to do. So I think we're all guessing what exactly your usecase is and we
On Tue, Feb 18, 2014 at 02:16:42PM -0800, David Rientjes wrote:
On Tue, 18 Feb 2014, Marcelo Tosatti wrote:
Lacking from your entire patchset is a specific example of what you want
to do. So I think we're all guessing what exactly your usecase is and we
aren't getting any help
On Mon, Feb 17, 2014 at 03:23:16PM -0800, David Rientjes wrote:
> On Mon, 17 Feb 2014, Luiz Capitulino wrote:
>
> > hugepages= and hugepages_node= are similar, but have different semantics.
> >
> > hugepagesz= and hugepages= create a pool of huge pages of the specified
> > size.
> > This means
On Mon, Feb 17, 2014 at 03:23:16PM -0800, David Rientjes wrote:
On Mon, 17 Feb 2014, Luiz Capitulino wrote:
hugepages= and hugepages_node= are similar, but have different semantics.
hugepagesz= and hugepages= create a pool of huge pages of the specified
size.
This means that the
On Tue, Feb 11, 2014 at 05:10:35PM +, Mel Gorman wrote:
> On Tue, Feb 11, 2014 at 01:26:29PM -0200, Marcelo Tosatti wrote:
> > > Or take a stab at allocating 1G pages at runtime. It would require
> > > finding properly aligned 1Gs worth of contiguous MAX_ORDER_NR_PAGE
On Tue, Feb 11, 2014 at 09:25:14AM +, Mel Gorman wrote:
> On Mon, Feb 10, 2014 at 06:54:20PM -0800, David Rientjes wrote:
> > On Mon, 10 Feb 2014, Luiz Capitulino wrote:
> >
> > > HugeTLB command-line option hugepages= allows the user to specify how many
> > > huge pages should be allocated
On Tue, Feb 11, 2014 at 09:25:14AM +, Mel Gorman wrote:
On Mon, Feb 10, 2014 at 06:54:20PM -0800, David Rientjes wrote:
On Mon, 10 Feb 2014, Luiz Capitulino wrote:
HugeTLB command-line option hugepages= allows the user to specify how many
huge pages should be allocated at boot. On
On Tue, Feb 11, 2014 at 05:10:35PM +, Mel Gorman wrote:
On Tue, Feb 11, 2014 at 01:26:29PM -0200, Marcelo Tosatti wrote:
Or take a stab at allocating 1G pages at runtime. It would require
finding properly aligned 1Gs worth of contiguous MAX_ORDER_NR_PAGES at
runtime. I would expect
+
> 2 files changed, 43 insertions(+), 21 deletions(-)
>
> --
> 1.8.3.1
Reviewed-by: Marcelo Tosatti
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-by: Marcelo Tosatti mtosa...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
level_pfn + level_size(level) - 1)) {
> dma_clear_pte(pte);
> domain_flush_cache(domain, pte, sizeof(*pte));
> free_pgtable_page(level_pte);
Reviewed-by: Marcelo Tosatti
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
);
Reviewed-by: Marcelo Tosatti mtosa...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ch.last_tsc_write = data;
> kvm->arch.last_tsc_khz = vcpu->arch.virtual_tsc_khz;
>
> - /* Reset of TSC must disable overshoot protection below */
> - vcpu->arch.hv_clock.tsc_timestamp = 0;
> vcpu->arch.last_guest_tsc = data;
>
> /* Keep track
-arch.virtual_tsc_khz;
- /* Reset of TSC must disable overshoot protection below */
- vcpu-arch.hv_clock.tsc_timestamp = 0;
vcpu-arch.last_guest_tsc = data;
/* Keep track of which generation this VCPU has synchronized to */
--
1.7.1
Reviewed-by: Marcelo Tosatti mtosa...@redhat.com
On Thu, Jan 09, 2014 at 03:08:25PM -0500, Hu Yaohui wrote:
> Hi Marcelo,
> Thanks for your replying!
> I hope you have a good day! I am sorry that it's not that obvious to
> me after I checked that function.
> If the remote vcpu is not in the same pcpu as the sender which calls
> kvm_vpcu_kick.
>
On Thu, Jan 09, 2014 at 03:08:25PM -0500, Hu Yaohui wrote:
Hi Marcelo,
Thanks for your replying!
I hope you have a good day! I am sorry that it's not that obvious to
me after I checked that function.
If the remote vcpu is not in the same pcpu as the sender which calls
kvm_vpcu_kick.
Before
On Wed, Jan 08, 2014 at 06:35:00PM -0500, Hu Yaohui wrote:
> Thanks a lot Marcelo!
>
> On Wed, Jan 8, 2014 at 6:25 PM, Marcelo Tosatti wrote:
> > On Wed, Jan 08, 2014 at 06:14:15PM -0500, Hu Yaohui wrote:
> >> Hi guys,
> >> I think you should be pretty fa
On Wed, Jan 08, 2014 at 06:35:00PM -0500, Hu Yaohui wrote:
Thanks a lot Marcelo!
On Wed, Jan 8, 2014 at 6:25 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Jan 08, 2014 at 06:14:15PM -0500, Hu Yaohui wrote:
Hi guys,
I think you should be pretty familiar with lapic. I would really
On Wed, Jan 08, 2014 at 06:14:15PM -0500, Hu Yaohui wrote:
> Hi guys,
> I think you should be pretty familiar with lapic. I would really
> appreciate it if someone could shed some lights on my problem
> regarding Guest TLB flush IPI.
> Supposed we get two vcpus 0 and 1.
> When vcpu#0 wants to
On Thu, Jan 02, 2014 at 05:14:11PM +0800, Chen Fan wrote:
> fix the 'vcpi' typos when apic_debug is enabled.
>
> Signed-off-by: Chen Fan
> ---
> arch/x86/kvm/lapic.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Applied, thanks.
--
To unsubscribe from this list: send the line
On Thu, Jan 02, 2014 at 05:14:11PM +0800, Chen Fan wrote:
fix the 'vcpi' typos when apic_debug is enabled.
Signed-off-by: Chen Fan chen.fan.f...@cn.fujitsu.com
---
arch/x86/kvm/lapic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Applied, thanks.
--
To unsubscribe from
On Wed, Jan 08, 2014 at 06:14:15PM -0500, Hu Yaohui wrote:
Hi guys,
I think you should be pretty familiar with lapic. I would really
appreciate it if someone could shed some lights on my problem
regarding Guest TLB flush IPI.
Supposed we get two vcpus 0 and 1.
When vcpu#0 wants to invalidate
Linus,
Please pull from
git://git.kernel.org/pub/scm/virt/kvm/kvm.git master
To receive the following KVM bug fixes
Jan Kiszka (2):
KVM: x86: Fix APIC map calculation after re-enabling
KVM: nVMX: Unconditionally uninit the MMU on nested vmexit
arch/x86/kvm/lapic.c |8
Linus,
Please pull from
git://git.kernel.org/pub/scm/virt/kvm/kvm.git master
To receive the following KVM bug fixes
Jan Kiszka (2):
KVM: x86: Fix APIC map calculation after re-enabling
KVM: nVMX: Unconditionally uninit the MMU on nested vmexit
arch/x86/kvm/lapic.c |8
On Sat, Dec 21, 2013 at 10:14:09AM -0800, Randy Dunlap wrote:
> On 12/21/13 08:21, Masanari Iida wrote:
> > Correct spelling typo in Documentations/virtual/kvm
> >
> > Signed-off-by: Masanari Iida
>
> Acked-by: Randy Dunlap
>
> Thanks.
Applied, thanks.
--
To unsubscribe from this list: send
On Sat, Dec 21, 2013 at 10:14:09AM -0800, Randy Dunlap wrote:
On 12/21/13 08:21, Masanari Iida wrote:
Correct spelling typo in Documentations/virtual/kvm
Signed-off-by: Masanari Iida standby2...@gmail.com
Acked-by: Randy Dunlap rdun...@infradead.org
Thanks.
Applied, thanks.
--
To
On Thu, Dec 05, 2013 at 11:30:27PM +0800, Xiao Guangrong wrote:
> In some cases, the lockless walker will do endless-walking on desc and
> without rewalk, consider this case:
>
> there are two descs: desc1 and desc2 who is pointed by desc1->next：
> desc1->next = desc2.
>
> CPU 0
On Thu, Dec 05, 2013 at 11:30:27PM +0800, Xiao Guangrong wrote:
> > Is it not the case that simply moving to the slow path once a maximum of
> > rewalks has been reached enough? (looks a like a good solution).
>
> In some cases, the lockless walker will do endless-walking on desc and
> without
GOn Tue, Dec 03, 2013 at 03:10:48PM +0800, Xiao Guangrong wrote:
> On 11/28/2013 04:53 PM, Xiao Guangrong wrote:
> > On 11/27/2013 03:31 AM, Marcelo Tosatti wrote:
> >> On Tue, Nov 26, 2013 at 11:21:37AM +0800, Xiao Guangrong wrote:
> >>> On 11/26/2013 0
GOn Tue, Dec 03, 2013 at 03:10:48PM +0800, Xiao Guangrong wrote:
On 11/28/2013 04:53 PM, Xiao Guangrong wrote:
On 11/27/2013 03:31 AM, Marcelo Tosatti wrote:
On Tue, Nov 26, 2013 at 11:21:37AM +0800, Xiao Guangrong wrote:
On 11/26/2013 02:12 AM, Marcelo Tosatti wrote:
On Mon, Nov 25, 2013
On Thu, Dec 05, 2013 at 11:30:27PM +0800, Xiao Guangrong wrote:
Is it not the case that simply moving to the slow path once a maximum of
rewalks has been reached enough? (looks a like a good solution).
In some cases, the lockless walker will do endless-walking on desc and
without rewalk,
On Thu, Dec 05, 2013 at 11:30:27PM +0800, Xiao Guangrong wrote:
In some cases, the lockless walker will do endless-walking on desc and
without rewalk, consider this case:
there are two descs: desc1 and desc2 who is pointed by desc1-next：
desc1-next = desc2.
CPU 0
On Tue, Nov 26, 2013 at 11:21:37AM +0800, Xiao Guangrong wrote:
> On 11/26/2013 02:12 AM, Marcelo Tosatti wrote:
> > On Mon, Nov 25, 2013 at 02:29:03PM +0800, Xiao Guangrong wrote:
> >>>> Also, there is no guarantee of termination (as long as sptes are
> >>>>
On Tue, Nov 26, 2013 at 11:10:19AM +0800, Xiao Guangrong wrote:
> On 11/25/2013 10:23 PM, Marcelo Tosatti wrote:
> > On Mon, Nov 25, 2013 at 02:48:37PM +0200, Avi Kivity wrote:
> >> On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
> >> wrote:
> >>>
>
On Tue, Nov 26, 2013 at 11:10:19AM +0800, Xiao Guangrong wrote:
On 11/25/2013 10:23 PM, Marcelo Tosatti wrote:
On Mon, Nov 25, 2013 at 02:48:37PM +0200, Avi Kivity wrote:
On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
On Nov 23, 2013, at 3:14 AM
On Tue, Nov 26, 2013 at 11:21:37AM +0800, Xiao Guangrong wrote:
On 11/26/2013 02:12 AM, Marcelo Tosatti wrote:
On Mon, Nov 25, 2013 at 02:29:03PM +0800, Xiao Guangrong wrote:
Also, there is no guarantee of termination (as long as sptes are
deleted with the correct timing). BTW, can't see
On Mon, Nov 25, 2013 at 02:29:03PM +0800, Xiao Guangrong wrote:
> >> Also, there is no guarantee of termination (as long as sptes are
> >> deleted with the correct timing). BTW, can't see any guarantee of
> >> termination for rculist nulls either (a writer can race with a lockless
> >> reader
GOn Mon, Nov 25, 2013 at 04:29:28PM +0200, Gleb Natapov wrote:
> On Mon, Nov 25, 2013 at 12:23:51PM -0200, Marcelo Tosatti wrote:
> > On Mon, Nov 25, 2013 at 02:48:37PM +0200, Avi Kivity wrote:
> > > On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
> > > wrote:
>
On Mon, Nov 25, 2013 at 02:48:37PM +0200, Avi Kivity wrote:
> On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
> wrote:
> >
> > On Nov 23, 2013, at 3:14 AM, Marcelo Tosatti wrote:
>
>
>
> I'm not really following, but note that parent_pte predates EPT (and
&g
On Mon, Nov 25, 2013 at 02:11:31PM +0800, Xiao Guangrong wrote:
>
> On Nov 23, 2013, at 3:14 AM, Marcelo Tosatti wrote:
>
> > On Wed, Oct 23, 2013 at 09:29:25PM +0800, Xiao Guangrong wrote:
> >> It likes nulls list and we use the pte-list as the nulls which can help
On Mon, Nov 25, 2013 at 02:48:37PM +0200, Avi Kivity wrote:
On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
On Nov 23, 2013, at 3:14 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
snip complicated stuff about parent_pte
I'm not really following
On Mon, Nov 25, 2013 at 02:11:31PM +0800, Xiao Guangrong wrote:
On Nov 23, 2013, at 3:14 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Oct 23, 2013 at 09:29:25PM +0800, Xiao Guangrong wrote:
It likes nulls list and we use the pte-list as the nulls which can help us
to
detect
GOn Mon, Nov 25, 2013 at 04:29:28PM +0200, Gleb Natapov wrote:
On Mon, Nov 25, 2013 at 12:23:51PM -0200, Marcelo Tosatti wrote:
On Mon, Nov 25, 2013 at 02:48:37PM +0200, Avi Kivity wrote:
On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote
On Mon, Nov 25, 2013 at 02:29:03PM +0800, Xiao Guangrong wrote:
Also, there is no guarantee of termination (as long as sptes are
deleted with the correct timing). BTW, can't see any guarantee of
termination for rculist nulls either (a writer can race with a lockless
reader indefinately,
On Wed, Oct 23, 2013 at 09:29:25PM +0800, Xiao Guangrong wrote:
> It likes nulls list and we use the pte-list as the nulls which can help us to
> detect whether the "desc" is moved to anther rmap then we can re-walk the rmap
> if that happened
>
> kvm->slots_lock is held when we do lockless
On Wed, Oct 23, 2013 at 09:29:25PM +0800, Xiao Guangrong wrote:
It likes nulls list and we use the pte-list as the nulls which can help us to
detect whether the desc is moved to anther rmap then we can re-walk the rmap
if that happened
kvm-slots_lock is held when we do lockless walking that
On Wed, Nov 20, 2013 at 10:20:09PM +0800, Xiao Guangrong wrote:
> > But what guarantee does userspace require, from GET_DIRTY_LOG, while vcpus
> > are
> > executing?
>
> Aha. Single calling GET_DIRTY_LOG is useless since new dirty page can be
> generated
> when GET_DIRTY_LOG is being returned.
On Wed, Nov 20, 2013 at 10:20:09PM +0800, Xiao Guangrong wrote:
But what guarantee does userspace require, from GET_DIRTY_LOG, while vcpus
are
executing?
Aha. Single calling GET_DIRTY_LOG is useless since new dirty page can be
generated
when GET_DIRTY_LOG is being returned. If user
On Tue, Nov 19, 2013 at 10:29:20PM -0200, Marcelo Tosatti wrote:
> A call to GET_DIRTY_LOG guarantees to return correct information about
> dirty pages before invocation of the previous GET_DIRTY_LOG call.
> Can you explain why it is OK to relax this rule?
That is, this might be OK, b
On Wed, Aug 07, 2013 at 12:06:49PM +0800, Xiao Guangrong wrote:
> On 08/07/2013 09:48 AM, Marcelo Tosatti wrote:
> > On Tue, Jul 30, 2013 at 09:02:02PM +0800, Xiao Guangrong wrote:
> >> Make sure we can see the writable spte before the dirt bitmap is visib
On Wed, Aug 07, 2013 at 12:06:49PM +0800, Xiao Guangrong wrote:
On 08/07/2013 09:48 AM, Marcelo Tosatti wrote:
On Tue, Jul 30, 2013 at 09:02:02PM +0800, Xiao Guangrong wrote:
Make sure we can see the writable spte before the dirt bitmap is visible
We do
On Tue, Nov 19, 2013 at 10:29:20PM -0200, Marcelo Tosatti wrote:
A call to GET_DIRTY_LOG guarantees to return correct information about
dirty pages before invocation of the previous GET_DIRTY_LOG call.
Can you explain why it is OK to relax this rule?
That is, this might be OK, but better
;move the entry: when a spte is deleted, we move the entry in the first
>desc to that position
>
> Both of these also can reduce cache miss
>
> Signed-off-by: Xiao Guangrong
Reviewed-by: Marcelo Tosatti
--
To unsubscribe from this list: send the line "unsubscribe linux
On Fri, Nov 15, 2013 at 03:09:13PM +0800, Xiao Guangrong wrote:
> On 11/15/2013 02:39 AM, Marcelo Tosatti wrote:
> > On Thu, Nov 14, 2013 at 01:15:24PM +0800, Xiao Guangrong wrote:
> >>
> >> Hi Marcelo,
> >>
> >> On 11/14/2013 08:36 AM, Marcelo Tosa
On Fri, Nov 15, 2013 at 03:09:13PM +0800, Xiao Guangrong wrote:
On 11/15/2013 02:39 AM, Marcelo Tosatti wrote:
On Thu, Nov 14, 2013 at 01:15:24PM +0800, Xiao Guangrong wrote:
Hi Marcelo,
On 11/14/2013 08:36 AM, Marcelo Tosatti wrote:
Any code location which reads the writable bit
to that position
Both of these also can reduce cache miss
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
Reviewed-by: Marcelo Tosatti mtosa...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
On Thu, Nov 14, 2013 at 01:15:24PM +0800, Xiao Guangrong wrote:
>
> Hi Marcelo,
>
> On 11/14/2013 08:36 AM, Marcelo Tosatti wrote:
>
> >
> > Any code location which reads the writable bit in the spte and assumes if
> > its not
> > set, tha
ons(+), 18 deletions(-)
Reviewed-by: Marcelo Tosatti
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
deletions(-)
Reviewed-by: Marcelo Tosatti mtosa...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
On Thu, Nov 14, 2013 at 01:15:24PM +0800, Xiao Guangrong wrote:
Hi Marcelo,
On 11/14/2013 08:36 AM, Marcelo Tosatti wrote:
Any code location which reads the writable bit in the spte and assumes if
its not
set, that the translation which the spte refers to is not cached
On Wed, Oct 23, 2013 at 09:29:22PM +0800, Xiao Guangrong wrote:
> Now we can flush all the TLBs out of the mmu lock without TLB corruption when
> write-proect the sptes, it is because:
> - we have marked large sptes readonly instead of dropping them that means we
> just change the spte from
On Wed, Oct 23, 2013 at 09:29:22PM +0800, Xiao Guangrong wrote:
Now we can flush all the TLBs out of the mmu lock without TLB corruption when
write-proect the sptes, it is because:
- we have marked large sptes readonly instead of dropping them that means we
just change the spte from writable
LE_LEVEL level) can be fast fixed
>
> Signed-off-by: Xiao Guangrong
Reviewed-by: Marcelo Tosatti
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
!!! At this point, the shadow page can still
> be
> writable due to the corrupt tlb entry
> Flush all TLB
>
> Signed-off-by: Xiao Guangrong
Reviewed-by: Marcelo Tosatti
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
be
writable due to the corrupt tlb entry
Flush all TLB
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
Reviewed-by: Marcelo Tosatti mtosa...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
Guangrong xiaoguangr...@linux.vnet.ibm.com
Reviewed-by: Marcelo Tosatti mtosa...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
/locking.txt to get more detail.
>*/
> - ret = fast_pf_fix_direct_spte(vcpu, iterator.sptep, spte);
> + ret = fast_pf_fix_direct_spte(vcpu, sp, iterator.sptep, spte);
> exit:
> trace_fast_page_fault(vcpu, gva, error_code, iterator.sptep,
>
:
trace_fast_page_fault(vcpu, gva, error_code, iterator.sptep,
spte, ret);
--
1.8.1.4
Reviewed-by: Marcelo Tosatti mtosa...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
p */
> + while (__gfn_to_hva_memslot(slot, gfn) & (page_size - 1))
> + page_size >>= 1;
> +
> /*
>* Pin all pages we are about to map in memory. This is
> * important because we unmap and un
))
+ page_size = 1;
+
/*
* Pin all pages we are about to map in memory. This is
* important because we unmap and unpin in 4kb steps later.
--
1.8.3.2
Reviewed-by: Marcelo Tosatti mtosa...@redhat.com
--
To unsubscribe from this list: send
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
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
On Thu, Oct 17, 2013 at 04:50:47PM +0200, Paolo Bonzini wrote:
> The loop was always using 0 as the index. This means that
> any rubbish after the first element of the array went undetected.
> It seems reasonable to assume that no KVM userspace did that.
It is not a typo, look at __kvm_set_xcr
On Thu, Oct 17, 2013 at 04:50:47PM +0200, Paolo Bonzini wrote:
The loop was always using 0 as the index. This means that
any rubbish after the first element of the array went undetected.
It seems reasonable to assume that no KVM userspace did that.
It is not a typo, look at __kvm_set_xcr when
On Wed, Oct 16, 2013 at 02:25:00PM -0400, Don Zickus wrote:
> On Fri, Oct 11, 2013 at 09:39:24PM -0300, Marcelo Tosatti wrote:
> > v2:
> > - do not create hung_task.h, move defines to sched.h (Don Zickus)
> > - switch patch order (Paolo)
>
> As long as it sol
On Wed, Oct 16, 2013 at 12:12:11PM +0300, Gleb Natapov wrote:
> On Tue, Oct 15, 2013 at 07:21:19PM -0300, Marcelo Tosatti wrote:
> > On Tue, Oct 15, 2013 at 06:57:05AM +0300, Gleb Natapov wrote:
> > > >
> > > > Why is it safe to allow access, by the lockles
On Wed, Oct 16, 2013 at 12:12:11PM +0300, Gleb Natapov wrote:
On Tue, Oct 15, 2013 at 07:21:19PM -0300, Marcelo Tosatti wrote:
On Tue, Oct 15, 2013 at 06:57:05AM +0300, Gleb Natapov wrote:
Why is it safe to allow access, by the lockless page write protect
side, to spt pointer
On Wed, Oct 16, 2013 at 02:25:00PM -0400, Don Zickus wrote:
On Fri, Oct 11, 2013 at 09:39:24PM -0300, Marcelo Tosatti wrote:
v2:
- do not create hung_task.h, move defines to sched.h (Don Zickus)
- switch patch order (Paolo)
As long as it solves kvm's problems, I am ok with it.
Marcelo
On Tue, Oct 15, 2013 at 06:57:05AM +0300, Gleb Natapov wrote:
> >
> > Why is it safe to allow access, by the lockless page write protect
> > side, to spt pointer for shadow page A that can change to a shadow page
> > pointer of shadow page B?
> >
> > Write protect spte of any page at will? Or
On Tue, Oct 15, 2013 at 06:57:05AM +0300, Gleb Natapov wrote:
Why is it safe to allow access, by the lockless page write protect
side, to spt pointer for shadow page A that can change to a shadow page
pointer of shadow page B?
Write protect spte of any page at will? Or verify that
On Sat, Oct 12, 2013 at 08:53:56AM +0300, Gleb Natapov wrote:
> On Fri, Oct 11, 2013 at 05:30:17PM -0300, Marcelo Tosatti wrote:
> > On Fri, Oct 11, 2013 at 08:38:31AM +0300, Gleb Natapov wrote:
> > > > n_max_mmu_pages is not a suitable limit to throttle freeing of pages via
On Sat, Oct 12, 2013 at 08:53:56AM +0300, Gleb Natapov wrote:
On Fri, Oct 11, 2013 at 05:30:17PM -0300, Marcelo Tosatti wrote:
On Fri, Oct 11, 2013 at 08:38:31AM +0300, Gleb Natapov wrote:
n_max_mmu_pages is not a suitable limit to throttle freeing of pages via
RCU (its too large
In certain occasions it is possible for a hung task detector
positive to be false: continuation from a paused VM, for example.
Add a method to reset detection, similar as is done
with other kernel watchdogs.
Signed-off-by: Marcelo Tosatti
Index: kvm/kernel/hung_task.c
v2:
- do not create hung_task.h, move defines to sched.h (Don Zickus)
- switch patch order (Paolo)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
901 - 1000 of 2527 matches
Mail list logo
