On Thu, 2011-12-22 at 12:21 +0200, Avi Kivity wrote:
> 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 Al
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
> > > (and
> > > updating api.txt if appropriate) -- what say you on
On Tue, 2011-12-20 at 16:17 +0100, Alexander Graf wrote:
> On 08.12.2011, at 03:55, Matt Evans wrote:
>
> > PPC KVM lacks these two capabilities, and as such a userland system must
> > assume
> > a max of 4 VCPUs (following api.txt). With these, a userland can determine
> > a more realistic limi
On Wed, 2011-12-14 at 23:01 +0800, bo kong wrote:
> It is lucky my machine boot normally, but I just do not know what is
> the vnc port of my machine, so I can't login my machine use vnc.
It should be printing the port information on one of the first lines
after starting the tool:
lappy kvm #
On Wed, 2011-12-14 at 11:34 +1100, Matt Evans wrote:
> On 13/12/11 21:23, Sasha Levin wrote:
> > On Tue, 2011-12-13 at 18:00 +1100, Matt Evans wrote:
> >> The second patch is a small fix for generic virtio code (now that we have a
> >> PPC build) which removes reliance o
On Tue, 2011-12-13 at 18:00 +1100, Matt Evans wrote:
> The second patch is a small fix for generic virtio code (now that we have a
> PPC build) which removes reliance on ioeventfds for PPC, which doesn't provide
> them.
Hm... ioeventfds are located in the generic code and should be available
on a
If you also got kernel patches that add __SANE_USERSPACE_TYPES__ to the
headers, and KVM_CAP_NR_VCPUS to KVM PPC, we can carry them in the KVM
tools tree as well.
On Fri, 2011-12-09 at 17:53 +1100, Matt Evans wrote:
> kvmtool's types.h includes , which by default on PPC64 brings in
> int-l64.h; de
On Fri, 2011-12-09 at 17:56 +1100, Matt Evans wrote:
> @@ -30,4 +31,18 @@ struct kvm_cpu {
> struct kvm_coalesced_mmio_ring *ring;
> };
>
> +/*
> + * As these are such simple wrappers, let's have them in the header so
> they'll
> + * be cheaper to call:
> + */
> +static inline bool kvm
On Fri, 2011-12-09 at 17:55 +1100, Matt Evans wrote:
> Add a --hugetlbfs commandline option to give a path to hugetlbfs-map guest
> memory (down in kvm__arch_init()). For x86, guest memory is a normal
> ANON mmap() if this option is not provided, otherwise a hugetlbfs mmap.
>
> Signed-off-by: Mat
On Thu, 2011-12-08 at 14:03 +1100, Matt Evans wrote:
> Hi Sasha,
>
> 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 th
On Wed, 2011-12-07 at 16:00 +0100, Alexander Graf wrote:
> On 07.12.2011, at 15:25, Avi Kivity wrote:
>
> > 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:
&
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 of you can loan a temporary ppc
> > shell for the upcoming
On Wed, 2011-12-07 at 18:28 +1100, Matt Evans wrote:
> On 07/12/11 18:24, Alexander Graf wrote:
> >
> > On 07.12.2011, at 08:19, Matt Evans wrote:
> >
> >> On 07/12/11 17:34, Sasha Levin wrote:
> >>> On Wed, 2011-12-07 at 17:17 +1100, Matt Evans wr
On Wed, 2011-12-07 at 17:17 +1100, Matt Evans wrote:
> On 06/12/11 19:20, Sasha Levin wrote:
> > Why is it getting moved out of generic code?
> >
> > This is used to determine the maximum amount of vcpus supported by the
> > host for a single guest, and as far as
On Wed, 2011-12-07 at 11:35 +1100, Matt Evans wrote:
> On 06/12/11 19:32, Sasha Levin wrote:
> > I'm seeing hugetlbfs_path being passed around, but I don't see anything
> > that actually does something with it.
> >
> > Did it get into a different patch? or m
On Tue, 2011-12-06 at 12:26 +0200, Pekka Enberg wrote:
> On Tue, Dec 6, 2011 at 5:42 AM, Matt Evans wrote:
> > The field size is currently wrong, read into a 32bit word instead of 16.
> > This
> > casues trouble when BE.
> >
> > Signed-off-by: Matt Evans
> > ---
> > tools/kvm/virtio/pci.c |
Awesome work :)
I really like the clean split we'll have between arch specific and
generic code after this series.
Not only we get ppc support, you've also made it very easy to add future
support for more archs.
On Tue, 2011-12-06 at 14:35 +1100, Matt Evans wrote:
> Hi,
>
>
> This patch series
Can we possibly do it by getting the generic code to call both
'kvm_cpu__arch_emulate_io' and 'kvm_cpu__arch_emulate_mmio', and have
the ppc code have an empty static for 'kvm_cpu__arch_emulate_io'?
On Tue, 2011-12-06 at 14:43 +1100, Matt Evans wrote:
> Different architectures will deal with MMIO
I'm seeing hugetlbfs_path being passed around, but I don't see anything
that actually does something with it.
Did it get into a different patch? or maybe it wasn't 'git add'ed?
On Tue, 2011-12-06 at 14:41 +1100, Matt Evans wrote:
> Some architectures may want to use hugetlbfs to mmap() their gues
It's optional, but when CONFIG_HAS_BFD is not defined symbol__init() is
defined as an empty static function.
Why was there a need to wrap it in a #ifdef here?
On Tue, 2011-12-06 at 14:41 +1100, Matt Evans wrote:
> CONFIG_HAS_BFD is optional, symbol.c inclusion is optional -- so make its init
> ca
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 cases where it happens?
On Tue, 2011-12-06 at 14:39 +1100, Matt Evans wrote:
> kvm_cpu__run() currently die()s if KVM_RUN returns non-zero. Some
> archite
Why is it getting moved out of generic code?
This is used to determine the maximum amount of vcpus supported by the
host for a single guest, and as far as I know KVM_CAP_NR_VCPUS and
KVM_CAP_MAX_VCPUS are not arch specific.
On Tue, 2011-12-06 at 14:39 +1100, Matt Evans wrote:
> Architectures can
Ingo actually got us to remove all the PRI* specifiers, but that was
back when we only did x86 :)
Ingo, does it make sense to use them now when we support different
architectures?
On Tue, 2011-12-06 at 14:38 +1100, Matt Evans wrote:
> On LP64 systems our u64s are just longs; remove the %llx'es in
For some reason I can't explain, I'm getting this error after applying
this patch:
Applying: kvm tools: Only build/init i8042 on x86
fatal: mode change for tools/kvm/bios.c, which is not in current HEAD
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way mer
On Wed, 2011-08-31 at 10:58 +0200, Alexander Graf wrote:
> +This capaobility enables interception of OSI hypercalls that otherwise would
capability
--
Sasha.
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More
25 matches
Mail list logo
