On 02/16/2012 10:41 PM, Scott Wood wrote:
> >>> Sharing the data structures is not need. Simply synchronize them before
> >>> lookup, like we do for ordinary registers.
> >>
> >> Ordinary registers are a few bytes. We're talking of dozens of kbytes here.
> >
> > A TLB way is a few dozen bytes, no
On 02/16/2012 09:34 PM, Alexander Graf wrote:
> On 16.02.2012, at 20:24, Avi Kivity wrote:
>
> > On 02/15/2012 04:08 PM, Alexander Graf wrote:
> >>>
> >>> Well, the scatter/gather registers I proposed will give you just one
> >>> register or all of
On 02/15/2012 04:08 PM, Alexander Graf wrote:
> >
> > Well, the scatter/gather registers I proposed will give you just one
> > register or all of them.
>
> One register is hardly any use. We either need all ways of a respective
> address to do a full fledged lookup or all of them.
I should have
On 02/16/2012 03:55 PM, Danny Kukawka wrote:
> arch/powerpc/kvm/book3s_hv.c: included 'linux/sched.h' twice,
> remove the duplicate.
>
Thanks, applied.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the bod
On 02/15/2012 03:37 PM, Alexander Graf wrote:
> On 15.02.2012, at 14:29, Avi Kivity wrote:
>
> > On 02/15/2012 01:57 PM, Alexander Graf wrote:
> >>>
> >>> Is an extra syscall for copying TLB entries to user space prohibitively
> >>> expensive?
>
On 02/07/2012 05:23 PM, Anthony Liguori wrote:
> On 02/07/2012 07:40 AM, Alexander Graf wrote:
>>
>> Why? For the HPET timer register for example, we could have a simple
>> MMIO hook that says
>>
>>on_read:
>> return read_current_time() - shared_page.offset;
>>on_write:
>> handle_
On 02/12/2012 09:10 AM, Takuya Yoshikawa wrote:
> Avi Kivity wrote:
>
> > > > Slot searching is quite fast since there's a small number of slots,
> > > > and we sort the larger ones to be in the front, so positive lookups are
> > > > fast. We c
On 02/15/2012 01:57 PM, Alexander Graf wrote:
> >
> > Is an extra syscall for copying TLB entries to user space prohibitively
> > expensive?
>
> The copying can be very expensive, yes. We want to have the possibility of
> exposing a very large TLB to the guest, in the order of multiple kentries.
On 02/07/2012 04:39 PM, Alexander Graf wrote:
> >
> > Syscalls are orthogonal to that - they're to avoid the fget_light() and to
> > tighten the vcpu/thread and vm/process relationship.
>
> How about keeping the ioctl interface but moving vcpu_run to a syscall then?
I dislike half-and-half inter
On 02/07/2012 03:40 PM, Alexander Graf wrote:
>>
>> Not sure we'll ever get there. For PPC, it will probably take another 1-2
years until we get the 32-bit targets stabilized. By then we will have new 64-bit
support though. And then the next gen will come out giving us even more new
constrain
On 02/07/2012 02:51 PM, Alexander Graf wrote:
On 07.02.2012, at 13:24, Avi Kivity wrote:
> On 02/07/2012 03:08 AM, Alexander Graf wrote:
>> I don't like the idea too much. On s390 and ppc we can set other vcpu's
interrupt status. How would that work in this model?
>
>
On 02/07/2012 03:08 AM, Alexander Graf wrote:
I don't like the idea too much. On s390 and ppc we can set other vcpu's
interrupt status. How would that work in this model?
It would be a "vm-wide syscall". You can also do that on x86 (through
KVM_IRQ_LINE).
I really do like the ioctl model
On 02/02/2012 05:04 AM, Alexander Graf wrote:
> Hi Avi / Marcelo,
>
> This is my current patch queue for ppc. Please pull.
>
Pulled, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a mess
On 01/23/2012 12:42 PM, Takuya Yoshikawa wrote:
> The last one is an RFC patch:
>
> I think it is better to refactor the rmap things, if needed, before
> other architectures than x86 starts large pages support.
>
Not commenting about the meat of the patches (not sufficiently recovered
yet), but ot
On 01/16/2012 03:18 PM, Alexander Graf wrote:
> Avi?
ACK!
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/maj
On 01/12/2012 12:41 PM, Paul Mackerras wrote:
> This moves __gfn_to_memslot() and search_memslots() from kvm_main.c to
> kvm_host.h to reduce the code duplication caused by the need for
> non-modular code in arch/powerpc/kvm/book3s_hv_rm_mmu.c to call
> gfn_to_memslot() in real mode.
>
> Rather tha
On 01/12/2012 01:39 AM, Alexander Graf wrote:
> On 12.01.2012, at 00:37, Scott Wood wrote:
>
> > Instead of keeping separate copies of struct kvm_vcpu_arch_shared (one in
> > the code, one in the docs) that inevitably fail to be kept in sync
> > (already sr[] is missing from the doc version), just
On 01/09/2012 09:29 PM, Scott Wood wrote:
> >
> > Best to include their signoffs, if possible.
>
> These patches are based in part on a bunch of different patches from
> these people (for which I did receive signoffs). I was reluctant to put
> their signoff directly on the new patches, since I di
On 12/21/2011 03:34 AM, Scott Wood wrote:
> Add processor support for e500mc, using hardware virtualization support
> (GS-mode).
>
> Current issues include:
> - No support for external proxy (coreint) interrupt mode in the guest.
>
> Includes work by Ashish Kalra ,
> Varun Sethi , and
> Liu Yu .
>
On 01/08/2012 06:41 PM, Alexander Graf wrote:
> On 08.01.2012, at 17:26, Avi Kivity wrote:
>
> > On 01/08/2012 06:21 PM, Alexander Graf wrote:
> >>>
> >>> well, that's not actually what x86 does, but what it should be doing.
> >>> The point
On 01/08/2012 06:21 PM, Alexander Graf wrote:
> >
> > well, that's not actually what x86 does, but what it should be doing.
> > The point is checking for signals after an exit is meaningless. You've
> > exited, so the guest can't be holding off a signal for the host. The
> > check after the exi
On 01/08/2012 05:37 PM, Alexander Graf wrote:
> On 08.01.2012, at 16:22, Avi Kivity wrote:
>
> > On 01/08/2012 05:11 PM, Alexander Graf wrote:
> >> On 08.01.2012, at 14:18, Avi Kivity wrote:
> >>
> >>> On 01/04/2012 03:10 AM, Alexander Graf wrote:
> &g
On 01/08/2012 05:16 PM, Alexander Graf wrote:
> >
> > Okay - I guess it's different to x86. And I think we had this
> > conversation before...
>
> In fact, this is the 3rd time I remember having this discussion on exactly
> this patch :).
Well it's only the first time this year, so it isn't so
On 01/08/2012 05:15 PM, Alexander Graf wrote:
> On 08.01.2012, at 14:29, Avi Kivity wrote:
>
> > On 01/04/2012 03:10 AM, Alexander Graf wrote:
> >> From: Paul Mackerras
> >>
> >> This adds the infrastructure to enable us to page out pages underneath
>
On 01/08/2012 05:11 PM, Alexander Graf wrote:
> On 08.01.2012, at 14:18, Avi Kivity wrote:
>
> > On 01/04/2012 03:10 AM, Alexander Graf wrote:
> >> From: Scott Wood
> >>
> >> Currently we check prior to returning from a lightweight exit,
> >> b
On 01/08/2012 04:53 PM, Alexander Graf wrote:
> On 08.01.2012, at 14:14, Avi Kivity wrote:
>
> > On 01/04/2012 03:10 AM, Alexander Graf wrote:
> >> From: Scott Wood
> >>
> >> The hardcoded behavior prevents proper SMP support.
> >>
>
On 01/08/2012 04:52 PM, Alexander Graf wrote:
> On 08.01.2012, at 14:13, Avi Kivity wrote:
>
> > On 01/04/2012 03:10 AM, Alexander Graf wrote:
> >> From: Scott Wood
> >>
> >> This implements a shared-memory API for giving host userspace access to
>
On 01/04/2012 03:10 AM, Alexander Graf wrote:
> From: Paul Mackerras
>
> This adds the infrastructure to enable us to page out pages underneath
> a Book3S HV guest, on processors that support virtualized partition
> memory, that is, POWER7. Instead of pinning all the guest's pages,
> we now look
On 01/04/2012 03:10 AM, Alexander Graf wrote:
> Our vcpu kick implementation differs a bit from x86 which resulted in us not
> disabling preemption during the kick. Get it a bit closer to what x86 does.
>
> Signed-off-by: Alexander Graf
> ---
> arch/powerpc/kvm/powerpc.c |7 ++-
> 1 files
On 01/04/2012 03:10 AM, Alexander Graf wrote:
> From: Scott Wood
>
> This allows additional registers to be accessed by the guest
> in PR-mode KVM without trapping.
>
> SPRG4-7 are readable from userspace. On booke, KVM will sync
> these registers when it enters the guest, so that accesses from
>
On 01/04/2012 03:10 AM, Alexander Graf wrote:
> From: Scott Wood
>
> Currently we check prior to returning from a lightweight exit,
> but not prior to initial entry.
>
> book3s already does a similar test.
>
> Signed-off-by: Scott Wood
> Signed-off-by: Alexander Graf
> ---
> arch/powerpc/kvm/bo
On 01/04/2012 03:10 AM, Alexander Graf wrote:
> With hugetlbfs support emerging on e500, we should also support KVM
> backing its guest memory by it.
>
> This patch adds support for hugetlbfs into the e500 shadow mmu code.
>
> Signed-off-by: Alexander Graf
> Acked-by: Scott Wood
>
> ---
>
> v1 ->
On 01/04/2012 03:10 AM, Alexander Graf wrote:
> From: Scott Wood
>
> The hardcoded behavior prevents proper SMP support.
>
> QEMU shall specify the vcpu's PIR as the vcpu id.
s/QEMU/userspace/
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send
On 01/04/2012 03:10 AM, Alexander Graf wrote:
> From: Scott Wood
>
> This implements a shared-memory API for giving host userspace access to
> the guest's TLB.
>
>
> +4.59 KVM_DIRTY_TLB
> +
> +Capability: KVM_CAP_SW_TLB
> +Architectures: ppc
> +Type: vcpu ioctl
> +Parameters: struct kvm_dirty_tl
On 01/05/2012 06:07 AM, Alexander Graf wrote:
> >
> > Hrm. Interesting idea. So you would basically reduce everything to __u64 by
> > padding smaller registers and splitting bigger ones into separate IDs? That
> > really is appealing, but might uglify the code quite a bit when remerging
> > big
On 01/04/2012 02:04 PM, Alexander Graf wrote:
> >> Not if we put the bit into flags. Then user space can just check the flags
> >> bitmap and know that it's there regardless of capabilities, because older
> >> kernels will set the bit to 0.
> >
> > It needs to detect that opt_features is availab
On 01/03/2012 04:13 PM, Alexander Graf wrote:
> On 03.01.2012, at 15:01, Avi Kivity wrote:
>
> > On 12/31/2011 08:16 AM, Liu Yu wrote:
> >> Add a new field opt_feature in struct kvm_ppc_pvinfo
> >> to tell userspace whether it support hcall idle.
> >>
On 12/31/2011 08:16 AM, Liu Yu wrote:
> Add a new field opt_feature in struct kvm_ppc_pvinfo
> to tell userspace whether it support hcall idle.
>
> diff --git a/include/linux/kvm.h b/include/linux/kvm.h
> index c107fae..5af21f3 100644
> --- a/include/linux/kvm.h
> +++ b/include/linux/kvm.h
> @@ -42
On 01/02/2012 05:23 PM, Alexander Graf wrote:
> > Or we could move the implementation into a header file, with an extra __
> > prefix, and have the C stubs call those inlines, so we have exactly on
> > instantiation. Your real mode code can then call the inlines.
>
> I like this version. That way
On 12/25/2011 12:58 PM, Alexander Graf wrote:
> Hi Avi,
>
> Here are a couple compile/trivial fixes for PPC KVM. Please make sure
> they all get to 3.2, worst case through -stable.
>
> I left out all the other fine commits that would be great to have in
> upstream due to limited testing on my side
On 12/20/2011 11:21 AM, Paul Mackerras wrote:
> This moves gfn_to_memslot(), and the functions it calls, that is,
> search_memslots() and __gfn_to_memslot(), from kvm_main.c to kvm_host.h
> so that gfn_to_memslot() can be called from non-modular code even
> when KVM is a module. On powerpc, the Bo
On 12/25/2011 01:32 PM, Avi Kivity wrote:
> On 12/25/2011 01:29 PM, Alexander Graf wrote:
> >
> > On 25.12.2011, at 12:03, Avi Kivity wrote:
> >
> > > On 12/25/2011 12:58 PM, Alexander Graf wrote:
> > >> Hi Avi,
> > >>
> > >> Her
On 12/25/2011 01:29 PM, Alexander Graf wrote:
>
> On 25.12.2011, at 12:03, Avi Kivity wrote:
>
> > On 12/25/2011 12:58 PM, Alexander Graf wrote:
> >> Hi Avi,
> >>
> >> Here are a couple compile/trivial fixes for PPC KVM. Please make sure
> >&
On 12/25/2011 12:58 PM, Alexander Graf wrote:
> Hi Avi,
>
> Here are a couple compile/trivial fixes for PPC KVM. Please make sure
> they all get to 3.2, worst case through -stable.
>
> I left out all the other fine commits that would be great to have in
> upstream due to limited testing on my side
On 12/24/2011 07:05 PM, Alexander Graf wrote:
> I was actually thinking of:
>
> commit dfc209648daf8ba4197e71376b76c95fd26fd272
> Author: Andreas Schwab
> Date: Tue Nov 8 07:17:39 2011 +
>
> KVM: PPC: protect use of kvmppc_h_pr
>
> kvmppc_h_pr is only available if CONFIG_KVM_BOO
On 12/22/2011 12:18 PM, Sasha Levin wrote:
> On Thu, 2011-12-22 at 12:03 +0200, Avi Kivity wrote:
> > On 12/08/2011 07:31 AM, Sasha Levin wrote:
> > > >
> > > > It sounds like Alex is considering KVM PPC's return value in this case
> > > > (an
On 12/08/2011 07:31 AM, Sasha Levin wrote:
> >
> > It sounds like Alex is considering KVM PPC's return value in this case (and
> > updating api.txt if appropriate) -- what say you on this patch? It actually
> > brings kvmtool's KVM_RUN return val check in line with QEMU's (also "< 0")
> > and
>
ed-off-by: Paul Mackerras
>
> Avi, mind to ack?
>
Acked-by: Avi Kivity
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/07/2011 05:01 PM, Alexander Graf wrote:
> Will do when I'm back on a keyboard ;).
Siri, write a patch for bugzilla #123456 and post it upstream.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body
On 12/07/2011 04:22 PM, Sasha Levin wrote:
> On Wed, 2011-12-07 at 16:11 +0200, Avi Kivity wrote:
> > On 12/07/2011 10:29 AM, Sasha Levin wrote:
> > > I also got another one, but it's **completely untested** (not even
> > > compiled). Alex, Matt, any chance one
On 12/07/2011 08:44 AM, Alexander Graf wrote:
> On 07.12.2011, at 01:32, Matt Evans wrote:
>
> > On 06/12/11 19:22, Sasha Levin wrote:
> >> If KVM_RUN can actually return anything besides 0 or -1 it may be also
> >> worthwhile to update Documentation/virtual/kvm/api.txt .
> >>
> >> What are the c
On 12/07/2011 10:29 AM, Sasha Levin wrote:
> I also got another one, but it's **completely untested** (not even
> compiled). Alex, Matt, any chance one of you can loan a temporary ppc
> shell for the upcoming tests of KVM tool/ppc KVM?
>
qemu offers free ppc shells
--
error compiling committee.c
On 11/21/2011 01:03 PM, Paul Mackerras wrote:
> On Sun, Nov 20, 2011 at 02:23:52PM +0200, Avi Kivity wrote:
> >
> > There is no "the VMA". There could be multiple VMAs, or none (with the
> > mmap() coming afterwards). You could do all the checks you want here,
On 11/17/2011 01:52 AM, Paul Mackerras wrote:
> This implements the low-level functions called by the MMU notifiers in
> the generic KVM code, and defines KVM_ARCH_WANT_MMU_NOTIFIER if
> CONFIG_KVM_BOOK3S_64_HV so that the generic KVM MMU notifiers get
> included.
>
> That means we also have to tak
On 11/17/2011 12:52 AM, Paul Mackerras wrote:
> From: Benjamin Herrenschmidt
>
> This adds support for adding PCI device I/O regions to the guest memory
> map, and for trapping guest accesses to emulated MMIO regions and
> delivering them to qemu for MMIO emulation. To trap guest accesses to
> em
On 11/17/2011 04:26 PM, Alexander Graf wrote:
> This reverts commit a15bd354f083f20f257db450488db52ac27df439.
>
> It exceeded the padding on the SREGS struct, rendering the ABI
> backwards-incompatible.
>
>
Thanks, applied and queued for 3.2.
--
error compiling committee.c: too many arguments to
On 11/10/2011 04:20 PM, Alexander Graf wrote:
>> looks like this is different in the 32x86 ABI.
>>
>> We can pad explicitly if you prefer.
> The size is 16 on 32-bit ppc -- the alignment of __u64 forces this. It
>
> I would prefer if we keep this stable :). There's no good reason to
> pad it - ppc
On 11/07/2011 09:48 PM, Jörg Sommer wrote:
> Hello everybody,
>
> I'm trying to build the kernel with the git commit-id
> 31555213f03bca37d2c02e10946296052f4ecfcd, but it fails
>
Alex, can we set up some buildbots for the ppc family, feeding on
kvm.git master/next?
--
I have a truly marvellous p
On 11/01/2011 06:16 PM, Scott Wood wrote:
> >
> > sizeof(struct kvm_tlb_dirty) == 12 for 32-bit userspace, but == 16 for
> > 64-bit userspace and the kernel. ABI structures must have the same
> > alignment and size for 32/64 bit userspace, or they need compat handling.
>
> The size is 16 on 32-b
On 11/01/2011 10:58 AM, Avi Kivity wrote:
> > > We already have another mechanism for such shared memory,
> > > mmap(vcpu_fd). x86 uses it for the coalesced mmio region as well as the
> > > traditional kvm_run area. Please consider using it.
> >
> > Wh
On 10/31/2011 08:52 PM, Scott Wood wrote:
> On 10/31/2011 07:50 AM, Avi Kivity wrote:
> > On 10/31/2011 09:53 AM, Alexander Graf wrote:
> >> +/* sesel is index into the set, not the whole array */
> >> +static void write_stlbe(struct kvmppc_vcpu_e500 *vcpu_e500,
> >
On 10/31/2011 10:12 PM, Scott Wood wrote:
> >> +4.59 KVM_DIRTY_TLB
> >> +
> >> +Capability: KVM_CAP_SW_TLB
> >> +Architectures: ppc
> >> +Type: vcpu ioctl
> >> +Parameters: struct kvm_dirty_tlb (in)
> >> +Returns: 0 on success, -1 on error
> >> +
> >> +struct kvm_dirty_tlb {
> >> + __u64 bitmap;
>
On 10/31/2011 09:53 AM, Alexander Graf wrote:
> With hugetlbfs support emerging on e500, we should also support KVM
> backing its guest memory by it.
>
> This patch adds support for hugetlbfs into the e500 shadow mmu code.
>
>
> @@ -673,12 +674,31 @@ static inline void kvmppc_e500_shadow_map(struct
On 10/31/2011 09:53 AM, Alexander Graf wrote:
> Right now we transfer a static struct every time we want to get or set
> registers. Unfortunately, over time we realize that there are more of
> these than we thought of before and the extensibility and flexibility of
> transferring a full struct ever
On 10/31/2011 09:53 AM, Alexander Graf wrote:
> This reverts commit 11d7596e18a712dc3bc29d45662ec111fd65946b. It exceeded
> the padding on the SREGS struct, rendering the ABI backwards-incompatible.
Can't find the commit hash. Please use hashes from the Linus tree when
possible.
This needs to be
On 10/31/2011 09:53 AM, Alexander Graf wrote:
> From: Scott Wood
>
> The hardcoded behavior prevents proper SMP support.
>
> QEMU shall specify the vcpu's PIR as the vcpu id.
>
>
Could also be kvm tool - we generally use the code name 'userspace' to
refer to qemu (but don't rewrite the patch on t
On 10/31/2011 09:53 AM, Alexander Graf wrote:
> From: Scott Wood
>
> This implements a shared-memory API for giving host userspace access to
> the guest's TLB.
>
>
> diff --git a/Documentation/virtual/kvm/api.txt
> b/Documentation/virtual/kvm/api.txt
> index 7945b0b..ab1136f 100644
> --- a/Docume
On 10/31/2011 09:53 AM, Alexander Graf wrote:
> From: Scott Wood
>
> Delay allocation of the shadow pid until we're ready to disable
> preemption and write the entry.
>
> @@ -507,21 +507,16 @@ static inline void kvmppc_e500_deliver_tlb_miss(struct
> kvm_vcpu *vcpu,
> vcpu_e500->mas7 = 0;
>
On 08/31/2011 04:02 PM, Alexander Graf wrote:
On 31.08.2011, at 14:52, Sasha Levin wrote:
> On Wed, 2011-08-31 at 10:58 +0200, Alexander Graf wrote:
>> +This capaobility enables interception of OSI hypercalls that otherwise
would
>capability
Oops :). Avi, you pulled that one in already.
On 08/25/2011 05:39 PM, Alexander Graf wrote:
Hi Avi,
This is my current patch queue for ppc. Please pull.
Thanks, pulled and applied the doc patch on top.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" i
On 08/31/2011 11:37 AM, Alexander Graf wrote:
On 31.08.2011, at 10:31, Avi Kivity wrote:
> On 08/25/2011 05:39 PM, Alexander Graf wrote:
>> Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap and
>> enable it for all Book3S targets. Enabling that CAP sw
On 08/25/2011 05:39 PM, Alexander Graf wrote:
Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap and
enable it for all Book3S targets. Enabling that CAP switches KVM into PAPR
mode.
#define KVM_CAP_PPC_RMA 65
#define KVM_CAP_MAX_VCPUS 66 /* returns max vcpus
On 08/09/2011 07:51 PM, Alexander Graf wrote:
Just put your own (or your employers'). If someone contributed to
the code they can add their copyrights (or ask you do do it before
inclusion).
It would be good to get Paul's or Ben's so that the unimportant
characters between the whitespace get
On 08/09/2011 07:46 PM, Alexander Graf wrote:
On 08/09/2011 06:40 PM, Avi Kivity wrote:
On 08/09/2011 07:31 PM, Alexander Graf wrote:
When running a PAPR guest, we need to handle a few hypercalls in
kernel space,
most prominently the page table invalidation (to sync the shadows).
So this
On 08/09/2011 07:31 PM, Alexander Graf wrote:
In KVM for Book3S PPC we currently have 2 implementations. There
is the PR based implementation which works on any POWER system
you pass in and the super fast HV implementation which requires
libre firmware (so almost nobody can use it).
Did you mea
On 08/09/2011 07:31 PM, Alexander Graf wrote:
When running a PAPR guest, we need to handle a few hypercalls in kernel space,
most prominently the page table invalidation (to sync the shadows).
So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried
to share the code with HV
On 07/04/2011 02:36 PM, Alexander Graf wrote:
>
> What intermediate steps? We can't add fields to the structure before we get
the extensibility infrastructure, but that's all.
If we add it now without extensibility code, we will have a kernel that only knows the
ioctl with the size as it is
On 07/04/2011 01:59 PM, Alexander Graf wrote:
On 03.07.2011, at 11:12, Avi Kivity wrote:
> On 07/03/2011 12:09 PM, Alexander Graf wrote:
>> >
>> > Right. The idea is that if KVM_FLAG_BLAH implies a field
kvm_struct::blah, then either both are present in the head
On 07/03/2011 12:09 PM, Alexander Graf wrote:
>
> Right. The idea is that if KVM_FLAG_BLAH implies a field kvm_struct::blah,
then either both are present in the headers, or none of them.
Yup, makes sense. I like the idea :). Gets rid of all the useless paddings and
reserved fields. We could
On 07/03/2011 12:00 PM, Alexander Graf wrote:
>> }
>>
>> Otherwise we might write over data the user expected. And that logic that
tells to copy_to_user how much data it actually takes to put all the information in
is not there today and would have to be added. You can even verify tha
On 07/03/2011 11:34 AM, Alexander Graf wrote:
>>
>> Yup, which requires knowledge in the code on what actually fits :). Logic
we don't have today.
>
> I don't follow. What knowledge is required? Please give an example.
Sure. Let's take an easy example Currently we have for get_pvinfo:
On 06/30/2011 07:33 PM, Alexander Graf wrote:
On 30.06.2011, at 18:00, Avi Kivity wrote:
> On 06/30/2011 06:22 PM, Alexander Graf wrote:
>>> Regarding that. There's another option - the ioctl code embeds the
structure size. So if we extend the ioctl parsing to pad up
On 06/30/2011 06:22 PM, Alexander Graf wrote:
Regarding that. There's another option - the ioctl code embeds the
structure size. So if we extend the ioctl parsing to pad up (or
truncate down) from the user's size to our size, and similarly in the
other direction, we can get away from this ugl
On 06/30/2011 06:04 PM, Alexander Graf wrote:
+4.64 KVM_PPC_SET_PLATFORM
+
+Capability: none
+Architectures: powerpc
+Type: vm ioctl
+Parameters: struct kvm_ppc_set_platform (in)
+Returns: 0, or -1 on error
+
+This is used by userspace to tell KVM what sort of platform it should
+emulate. The re
On 06/29/2011 02:58 PM, Josh Boyer wrote:
>> This makes me wonder if a similar thing might eventually be usable for
>> running an i686 or x32 guest on an x86_64 KVM host. I have no idea if
>> that is even theoretically possible, but if it is it might be better to
>> rename the ioctl to be ar
On 06/19/2011 04:42 PM, Alexander Graf wrote:
Hi Avi,
here's the updated pull request.
Alex
The following changes since commit a94925fed08e72213eabf611744b12af3e832218:
Yang, Wei (1):
KVM: Enable ERMS feature support for KVM
are available in the git repository at:
git://githu
On 06/09/2011 06:57 PM, Paolo Bonzini wrote:
-- 8< -
From Mon Sep 17 00:00:00 2001
From: Paolo Bonzini
Date: Thu, 9 Jun 2011 17:48:50 +0200
Subject: [PATCH] KVM: fix documentation for KVM_SET_SIGNAL_MAS
On 06/19/2011 03:53 PM, Alexander Graf wrote:
On 19.06.2011, at 11:04, Avi Kivity wrote:
> On 06/17/2011 05:49 PM, Alexander Graf wrote:
>> KVM has an ioctl to define which signal mask should be used while running
>> inside VCPU_RUN. At least for big endian systems, this ma
On 06/17/2011 05:49 PM, Alexander Graf wrote:
Hi Avi/Marcelo,
This is my current patch queue for PPC KVM. Please apply.
It's all good except for patch 3 which is duplicate. Can you drop it
and re-post the pull URL? I could apply all ^ 3 but prefer to pull.
--
error compiling committee.c:
On 06/17/2011 05:49 PM, Alexander Graf wrote:
KVM has an ioctl to define which signal mask should be used while running
inside VCPU_RUN. At least for big endian systems, this mask is different
on 32-bit and 64-bit systems (though the size is identical).
Add a compat wrapper that converts the mas
On 06/08/2011 03:45 AM, Alexander Graf wrote:
KVM has an ioctl to define which signal mask should be used while running
inside VCPU_RUN. At least for big endian systems, this mask is different
on 32-bit and 64-bit systems (though the size is identical).
Add a compat wrapper that converts the mas
On 03/30/2011 09:28 AM, Alexander Graf wrote:
On 29.03.2011, at 23:49, Scott Wood wrote:
> Return the actual host SVR for now, as we already do for PVR. Eventually
> we may support Qemu overriding PVR/SVR if the situation is appropriate,
> once we implement KVM_SET_SREGS on e500.
Haha - may
On 02/15/2011 05:59 PM, Dushyant Bansal wrote:
2. How to configure makefiles to get output of printk statements
inside kvm/arch/powerpc/kvm/trace.h
Better don't make them printks - just use the tracing framework. I'd
write up a small howto here myself, but I'm pretty much on the jump
to my plan
On 02/07/2011 07:30 PM, Yoder Stuart-B08248 wrote:
> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org]
> On Behalf Of Avi Kivity
> Sent: Monday, February 07, 2011 11:14 AM
> To: Alexander Graf
> Cc: Wood Scott-B0
On 02/03/2011 11:19 AM, Alexander Graf wrote:
>
> I have no idea what things will look like 10 years down the road, but
> currently e500mc has 576 entries (512 TLB0, 64 TLB1).
That sums up to 64 * 576 bytes, which is 36kb. Ouch. Certainly nothing we want
to transfer every time qemu feels like
On 01/19/2011 12:05 PM, ViniCrane L. wrote:
Avi,
Do you have any plan to support AIX guest?
Do you mean on the power architecture? I'm sure Alex would know.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" i
On 12/15/2010 01:32 PM, Sethi Varun-B16395 wrote:
> >
> > But KVM would be aware of guest page mappings, so access permissions
> > for any particular mapping can be controlled by KVM.
>
> kvm isn't aware of all guest mappings (only those that were instantiated
> in shadow tlb/pagetables).
On 12/15/2010 01:16 PM, Sethi Varun-B16395 wrote:
> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-
> ow...@vger.kernel.org] On Behalf Of Avi Kivity
> Sent: Tuesday, December 14, 2010 9:18 PM
> To: Yoder Stuart-B08248
> Cc: Hollis Bl
On 12/14/2010 07:53 PM, Hollis Blanchard wrote:
On 12/14/2010 12:48 AM, Avi Kivity wrote:
On 12/13/2010 07:17 PM, Hollis Blanchard wrote:
Rewriting is dangerous if the guest is unaware of it. As soon as
it is made aware of it, it might as well actually do it in the best
way that suits it
On 12/14/2010 05:45 PM, Yoder Stuart-B08248 wrote:
> -Original Message-
> From: Avi Kivity [mailto:a...@redhat.com]
> Sent: Tuesday, December 14, 2010 2:49 AM
> To: Hollis Blanchard
> Cc: Yoder Stuart-B08248; Alexander Graf; kvm-ppc@vger.kernel.org
> Subject:
101 - 200 of 462 matches
Mail list logo
