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
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
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
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
* Sasha Levin levinsasha...@gmail.com wrote:
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?
Not at all - ppc should use a sane u64/s64 definition, i.e.
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
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
On Tue, Dec 6, 2011 at 10:07 AM, Sasha Levin levinsasha...@gmail.com wrote:
The code doesn't build after this patch due to missing header issues
which you fixed in patches #10 #11. Could you please move those two to
the beginning of the series for the sake of bisectablilty?
I did that myself.
On Tue, Dec 6, 2011 at 5:40 AM, Matt Evans m...@ozlabs.org wrote:
term_getc()'s int c has one byte written into it (at its lowest address) by
read_in_full(). This is expected to be the least significant byte, but that
isn't the case on BE! Use correct type, unsigned char. A similar issue
* Paul Mackerras pau...@samba.org wrote:
On Tue, Dec 06, 2011 at 09:28:27AM +0100, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
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
On Tue, Dec 6, 2011 at 5:40 AM, Matt Evans m...@ozlabs.org wrote:
cpios are valid as initrds too, so allow them through the check.
Signed-off-by: Matt Evans m...@ozlabs.org
---
tools/kvm/kvm.c | 8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/kvm/kvm.c
On Tue, Dec 06, 2011 at 12:25:29PM +0200, Pekka Enberg wrote:
On Tue, Dec 6, 2011 at 5:42 AM, Matt Evans m...@ozlabs.org wrote:
vesa, pci-shmem and virtio-pci devices need to set up config space with
little-endian conversions (as config space is LE). The pci_config_address
bitfield also
On Tue, Dec 6, 2011 at 5:41 AM, Matt Evans m...@ozlabs.org wrote:
This patch passes the initrd fd and commandline to load_flat_binary(), which
may
be used to load both the kernel an initrd (stashing or inserting the
commandline as appropriate) in the same way that load_bzimage() does. This
On Tue, Dec 6, 2011 at 1:28 PM, Asias He asias.he...@gmail.com wrote:
@@ -116,8 +116,7 @@ static bool virtio_pci__io_in(struct ioport *ioport,
struct kvm *kvm, u16 port,
break;
case VIRTIO_PCI_QUEUE_NUM:
val = vtrans-virtio_ops-get_size_vq(kvm, vpci-dev,
On Tue, Dec 6, 2011 at 12:28 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Tue, Dec 06, 2011 at 12:25:29PM +0200, Pekka Enberg wrote:
On Tue, Dec 6, 2011 at 5:42 AM, Matt Evans m...@ozlabs.org wrote:
vesa, pci-shmem and virtio-pci devices need to set up config space with
little-endian
On Tue, Dec 06, 2011 at 03:03:00PM +1100, Paul Mackerras wrote:
I'm not sure why yet, but commit 8a97c432 (KVM: PPC: booke: Improve
timer register emulation) in Alex's kvm-ppc-next branch is breaking
Book3S HV KVM on POWER7. Guest cpus fail to spin up, and even with
just one cpu, the guest
On 06.12.2011, at 12:43, Paul Mackerras wrote:
On Tue, Dec 06, 2011 at 03:03:00PM +1100, Paul Mackerras wrote:
I'm not sure why yet, but commit 8a97c432 (KVM: PPC: booke: Improve
timer register emulation) in Alex's kvm-ppc-next branch is breaking
Book3S HV KVM on POWER7. Guest cpus fail to
On Tue, Dec 06, 2011 at 01:41:56PM +0200, Pekka Enberg wrote:
On Tue, Dec 6, 2011 at 12:28 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Tue, Dec 06, 2011 at 12:25:29PM +0200, Pekka Enberg wrote:
On Tue, Dec 6, 2011 at 5:42 AM, Matt Evans m...@ozlabs.org wrote:
vesa, pci-shmem and
On Tue, 2011-12-06 at 15:47 +0400, Cyrill Gorcunov wrote:
On Tue, Dec 06, 2011 at 01:41:56PM +0200, Pekka Enberg wrote:
On Tue, Dec 6, 2011 at 12:28 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Tue, Dec 06, 2011 at 12:25:29PM +0200, Pekka Enberg wrote:
On Tue, Dec 6, 2011 at 5:42 AM,
On 12/06/2011 06:24 PM, Pekka Enberg wrote:
On Tue, Dec 6, 2011 at 5:40 AM, Matt Evans m...@ozlabs.org wrote:
term_getc()'s int c has one byte written into it (at its lowest address) by
read_in_full(). This is expected to be the least significant byte, but that
isn't the case on BE! Use
On Tue, 2011-12-06 at 12:26 +0200, Pekka Enberg wrote:
On Tue, Dec 6, 2011 at 5:42 AM, Matt Evans m...@ozlabs.org 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 m...@ozlabs.org
---
On Tue, Dec 06, 2011 at 03:29:00PM +0200, Pekka Enberg wrote:
Hehe, this is because it should be rtaher defined as
union pci_config_address {
struct {
#if __BYTE_ORDER == __LITTLE_ENDIAN
unsignedzeros : 2;
unsignedregister_number : 6;
#else
...
On 12/05/2011 10:05 PM, Matt Evans wrote:
This patch adds a new arch directory, powerpc, basic file structure, register
setup and where necessary stubs out arch-specific functions (e.g. interrupts,
runloop exits) that later patches will provide. The target is an
SPAPR-compliant PPC64 machine
On Tue, Dec 6, 2011 at 8:03 PM, Scott Wood scottw...@freescale.com wrote:
I'm seeing a lot of double-underscores -- is this common style in KVM
tool? It's reserved for use by the compiler and system library. It's
common in the kernel (though not used like this for namespace
prefixes), but
On 12/06/2011 12:33 PM, Pekka Enberg wrote:
On Tue, Dec 6, 2011 at 8:03 PM, Scott Wood scottw...@freescale.com wrote:
I'm seeing a lot of double-underscores -- is this common style in KVM
tool? It's reserved for use by the compiler and system library. It's
common in the kernel (though not
On 12/05/2011 09:37 PM, Matt Evans wrote:
Not every architecture has an i8042 kbd controller, so only use this when
building for x86.
There are non-x86 machines that have one, though -- does KVM tool have
any sort of target configuration mechanism?
-Scott
--
To unsubscribe from this list:
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 cases where it happens?
Well, on PPC the internal kvmppc_run_vcpu() returns either RESUME_GUEST (which
stays
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 maybe it wasn't 'git add'ed?
It's actually moved in preparation for the later [PATCH 1/8] kvm tools: Add
Hi Cyrill,
On 06/12/11 23:04, Cyrill Gorcunov wrote:
On Tue, Dec 06, 2011 at 12:29:48PM +0200, Pekka Enberg wrote:
...
Otherwise looks OK to me. Cyrill?
It might be not seen from patch (or my local kvm repo
is not yet updated well) but I somehow miss who will be
reading initrd in case
Hi Asias,
On 06/12/11 23:00, Asias He wrote:
On 12/06/2011 06:24 PM, Pekka Enberg wrote:
On Tue, Dec 6, 2011 at 5:40 AM, Matt Evans m...@ozlabs.org wrote:
term_getc()'s int c has one byte written into it (at its lowest address) by
read_in_full(). This is expected to be the least significant
On 06/12/11 19:26, Sasha Levin wrote:
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?
That's an excellent question and I think the true answer is just embarrassing so
I'll just drop
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 maybe it wasn't 'git add'ed?
It's actually
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 I know KVM_CAP_NR_VCPUS and
KVM_CAP_MAX_VCPUS are not arch specific.
I checked api.txt and you're
On Wed, Dec 07, 2011 at 11:42:27AM +1100, Matt Evans wrote:
Hi Cyrill,
On 06/12/11 23:04, Cyrill Gorcunov wrote:
On Tue, Dec 06, 2011 at 12:29:48PM +0200, Pekka Enberg wrote:
...
Otherwise looks OK to me. Cyrill?
It might be not seen from patch (or my local kvm repo
is not yet
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 I know KVM_CAP_NR_VCPUS and
On 06/12/11 19:54, Sasha Levin wrote:
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'?
Yeah that's nicer, I'll make that change... less
On 07.12.2011, at 01:32, Matt Evans m...@ozlabs.org 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 cases where it happens?
Well, on PPC the internal
Hi Ingo,
On 06/12/11 21:24, Ingo Molnar wrote:
* Paul Mackerras pau...@samba.org wrote:
On Tue, Dec 06, 2011 at 09:28:27AM +0100, Ingo Molnar wrote:
* Sasha Levin levinsasha...@gmail.com wrote:
Ingo actually got us to remove all the PRI* specifiers, but
that was back when we only did
On 07/12/11 17:34, Sasha Levin wrote:
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 I know
On 07.12.2011, at 08:19, Matt Evans m...@ozlabs.org wrote:
On 07/12/11 17:34, Sasha Levin wrote:
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
On 07/12/11 05:59, Scott Wood wrote:
On 12/05/2011 09:37 PM, Matt Evans wrote:
Not every architecture has an i8042 kbd controller, so only use this when
building for x86.
There are non-x86 machines that have one, though -- does KVM tool have
any sort of target configuration mechanism?
See
41 matches
Mail list logo
