On Fri, Aug 24, 2012 at 07:29:53PM +1000, Paul Mackerras wrote:
> On Thu, Aug 23, 2012 at 10:55:37AM -0300, Marcelo Tosatti wrote:
>
> > There are a number of options to consider:
> >
> > 1) Merge the current patchset from Paul, which has two downsides:
> > 1-1) It contains an unfixable race.
On Thu, Aug 23, 2012 at 10:55:37AM -0300, Marcelo Tosatti wrote:
> There are a number of options to consider:
>
> 1) Merge the current patchset from Paul, which has two downsides:
> 1-1) It contains an unfixable race.
The race being that new HTPEs using the old base address could get
inser
On Sat, Aug 18, 2012 at 06:32:25AM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2012-08-17 at 15:39 -0300, Marcelo Tosatti wrote:
> > On Fri, Aug 17, 2012 at 05:06:18PM +1000, Benjamin Herrenschmidt wrote:
> > > On Wed, 2012-08-15 at 14:59 -0300, Marcelo Tosatti wrote:
> > > >
> > > > The guest
On 08/17/2012 09:39 PM, Marcelo Tosatti wrote:
>
> Yes. Well, Avi mentioned earlier that there are users for change of GPA
> base. But, if my understanding is correct, the code that emulates
> change of BAR in QEMU is:
>
> /* now do the real mapping */
> if (r->addr != PCI_BAR_UNM
On Fri, 2012-08-17 at 15:39 -0300, Marcelo Tosatti wrote:
> On Fri, Aug 17, 2012 at 05:06:18PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2012-08-15 at 14:59 -0300, Marcelo Tosatti wrote:
> > >
> > > The guest should not expect memory accesses to an address
> > > to behave sanely while chang
On Fri, Aug 17, 2012 at 05:06:18PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2012-08-15 at 14:59 -0300, Marcelo Tosatti wrote:
> >
> > The guest should not expect memory accesses to an address
> > to behave sanely while changing a BAR anyway.
> >
> > Yes, compatibility for change of GPA base
On Wed, 2012-08-15 at 14:59 -0300, Marcelo Tosatti wrote:
>
> The guest should not expect memory accesses to an address
> to behave sanely while changing a BAR anyway.
>
> Yes, compatibility for change of GPA base can be done in the
> kernel. I can look into it next week if nobody has done so at
On Wed, Aug 15, 2012 at 12:26:05PM +0300, Avi Kivity wrote:
> On 08/14/2012 01:04 AM, Marcelo Tosatti wrote:
> > On Mon, Aug 13, 2012 at 01:34:11PM -0300, Marcelo Tosatti wrote:
> >> On Sat, Aug 11, 2012 at 10:37:54AM +1000, Paul Mackerras wrote:
> >> > On Fri, Aug 10, 2012 at 03:35:53PM -0300, Mar
On 08/14/2012 01:04 AM, Marcelo Tosatti wrote:
> On Mon, Aug 13, 2012 at 01:34:11PM -0300, Marcelo Tosatti wrote:
>> On Sat, Aug 11, 2012 at 10:37:54AM +1000, Paul Mackerras wrote:
>> > On Fri, Aug 10, 2012 at 03:35:53PM -0300, Marcelo Tosatti wrote:
>> > > There's no plan. I just wanted to confirm
On 08/13/2012 07:34 PM, Marcelo Tosatti wrote:
>
> Avi, Gleb, Alex, do you know why it is necessary to support change of
> GPA base again?
BAR moving around.
> Without taking into consideration backwards compatibility, userspace
> can first delete the slot and later create a new one.
Current
On Mon, Aug 13, 2012 at 01:34:11PM -0300, Marcelo Tosatti wrote:
> On Sat, Aug 11, 2012 at 10:37:54AM +1000, Paul Mackerras wrote:
> > In fact I need to remove any translations in the old range *before*
> > the new memslot gets committed, whereas this happens after that.
> > This is why I was doing
On Mon, Aug 13, 2012 at 01:34:11PM -0300, Marcelo Tosatti wrote:
> On Sat, Aug 11, 2012 at 10:37:54AM +1000, Paul Mackerras wrote:
> > On Fri, Aug 10, 2012 at 03:35:53PM -0300, Marcelo Tosatti wrote:
> > > There's no plan. I just wanted to confirm this before converting
> > > to per-memslot flush.
On Sat, Aug 11, 2012 at 10:37:54AM +1000, Paul Mackerras wrote:
> On Fri, Aug 10, 2012 at 03:35:53PM -0300, Marcelo Tosatti wrote:
> > There's no plan. I just wanted to confirm this before converting
> > to per-memslot flush.
> >
> > 1) __kvm_set_memory_region line 807:
> >
> >
On Fri, Aug 10, 2012 at 03:35:53PM -0300, Marcelo Tosatti wrote:
> There's no plan. I just wanted to confirm this before converting
> to per-memslot flush.
>
> 1) __kvm_set_memory_region line 807:
>
> * - gfn_to_hva (kvm_read_guest, gfn_to_pfn)
> * - k
On Fri, Aug 10, 2012 at 11:09:09AM +0900, Takuya Yoshikawa wrote:
> On Thu, 9 Aug 2012 22:25:32 -0300
> Marcelo Tosatti wrote:
>
> > I'll send a patch to flush per memslot in the next days, you can work
> > out the PPC details in the meantime.
Not anymore.
> Are you going to implement that usin
On Thu, 9 Aug 2012 22:25:32 -0300
Marcelo Tosatti wrote:
> I'll send a patch to flush per memslot in the next days, you can work
> out the PPC details in the meantime.
Are you going to implement that using slot_bitmap?
Since I'm now converting kvm_mmu_slot_remove_write_access() to
rmap based pr
On Fri, Aug 10, 2012 at 10:34:39AM +1000, Paul Mackerras wrote:
> On Thu, Aug 09, 2012 at 03:16:12PM -0300, Marcelo Tosatti wrote:
>
> > The !memslot->npages case is handled in __kvm_set_memory_region
> > (please read that part, before kvm_arch_prepare_memory_region() call).
> >
> > kvm_arch_flus
On Thu, Aug 09, 2012 at 10:25:32PM -0300, Marcelo Tosatti wrote:
> On Fri, Aug 10, 2012 at 10:34:39AM +1000, Paul Mackerras wrote:
> > On Thu, Aug 09, 2012 at 03:16:12PM -0300, Marcelo Tosatti wrote:
> >
> > > The !memslot->npages case is handled in __kvm_set_memory_region
> > > (please read that
On Thu, Aug 09, 2012 at 03:16:12PM -0300, Marcelo Tosatti wrote:
> The !memslot->npages case is handled in __kvm_set_memory_region
> (please read that part, before kvm_arch_prepare_memory_region() call).
>
> kvm_arch_flush_shadow should be implemented.
Book3S HV doesn't have shadow page tables p
On Mon, Aug 06, 2012 at 08:06:03PM +1000, Paul Mackerras wrote:
> >From 44067a8ee15021583636bea4cc1d47e5370b8397 Mon Sep 17 00:00:00 2001
> From: Paul Mackerras
> Date: Mon, 30 Jul 2012 16:40:54 +1000
> Subject:
>
> At present the HV style of KVM doesn't handle deletion or modification
> of memo
>From 44067a8ee15021583636bea4cc1d47e5370b8397 Mon Sep 17 00:00:00 2001
From: Paul Mackerras
Date: Mon, 30 Jul 2012 16:40:54 +1000
Subject:
At present the HV style of KVM doesn't handle deletion or modification
of memory slots correctly. Deletion occurs when userspace does the
KVM_SET_USER_MEMO
21 matches
Mail list logo
