On 11 December 2011 10:24, Christoffer Dall
wrote:
> The following series implements KVM support for ARM processors,
> specifically on the Cortex A-15 platform.
> Still on the to-do list:
> - Reuse VMIDs
> - Fix SMP host support
> - Fix SMP guest support
> - Support guest Thumb mode for MMIO
On 15 November 2011 16:47, Sasha Levin wrote:
> + vmmio->hdr = (struct virtio_mmio_hdr) {
> + .magic = {'v', 'i', 'r', 't'},
> + .version = 1,
> + .device_id = device_id - 0x1000 + 1,
> + .vendor_id = PCI_VENDO
On 9 November 2011 11:06, Pawel Moll wrote:
> On Wed, 2011-11-09 at 10:55 +, Sasha Levin wrote:
>> On Wed, 2011-11-09 at 10:47 +, Pawel Moll wrote:
>> > Yep, it's actually already in 3.2-rc1 (drivers/virtio/virtio_mmio.c) and
>> > in the spec (see Appendix X). And actually the control regi
On 24 October 2011 12:35, Paolo Bonzini wrote:
> On 10/24/2011 01:04 PM, Juan Quintela wrote:
>> Please send in any agenda items you are interested in covering.
>
> - What's left to merge for 1.0.
Things on my list, FWIW:
* current target-arm pullreq
* PL041 support (needs another patch round t
On 14 September 2011 16:07, Avi Kivity wrote:
> I would like to carry out an online code review of the memory API so that
> more people are familiar with the internals, and perhaps even to catch some
> bugs or deficiency. I'd like to use the next kvm conference call slot for
> this (Tuesday 1400
On 8 August 2011 18:07, Avi Kivity wrote:
> This tells the sysbus code it need not use IO_MEM_UNASSIGNED.
>
> Signed-off-by: Avi Kivity
> ---
> hw/arm11mpcore.c | 7 ++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/hw/arm11mpcore.c b/hw/arm11mpcore.c
> index b47707f
On 11 August 2011 17:29, Avi Kivity wrote:
> -static uint32_t pci_vpb_config_readl (void *opaque, target_phys_addr_t addr)
> +static uint64_t pci_vpb_config_read(void *opaque, target_phys_addr_t addr,
> + unsigned size)
> {
> uint32_t val;
> - val = pci_d
On 8 August 2011 18:07, Avi Kivity wrote:
> -static uint32_t pci_vpb_config_readb (void *opaque, target_phys_addr_t addr)
> +static uint64_t pci_vpb_config_read(void *opaque, target_phys_addr_t addr,
> + unsigned size)
> {
> uint32_t val;
> - val = pci_da
On 9 August 2011 10:26, Avi Kivity wrote:
> On 08/09/2011 12:23 PM, Peter Maydell wrote:
>>
>> On 9 August 2011 10:02, Avi Kivity wrote:
>> > +static const MemoryRegionOps omap_gpmc_ops = {
>> > + .read = omap_gpmc_read,
>> > + .write
On 9 August 2011 10:02, Avi Kivity wrote:
> +static const MemoryRegionOps omap_gpmc_ops = {
> + .read = omap_gpmc_read,
> + .write = omap_gpmc_write,
> + .endianness = DEVICE_NATIVE_ENDIAN,
> + .valid = {
> + .min_access_size = 4,
> + .max_access_size = 4,
> + },
> };
On 9 August 2011 08:41, Avi Kivity wrote:
> On 08/09/2011 10:37 AM, Peter Maydell wrote:
>>
>> On 9 August 2011 07:34, Avi Kivity wrote:
>> > Also, my patchset focuses on mechanical transformations. It is already
>> > risky enough in terms of regressions,
On 8 August 2011 18:06, Avi Kivity wrote:
> diff --git a/hw/tusb6010.h b/hw/tusb6010.h
> new file mode 100644
> index 000..6faa94d
> --- /dev/null
> +++ b/hw/tusb6010.h
> @@ -0,0 +1,10 @@
> +#ifndef TUSB6010_H
> +#define TUSB6010_H
> +
> +typedef struct TUSBState TUSBState;
> +TUSBState *tusb6
On 9 August 2011 07:34, Avi Kivity wrote:
> Also, my patchset focuses on mechanical transformations. It is already
> risky enough in terms of regressions, I'm not going to rewrite/improve all
> of qemu; if you want those callbacks removed, you will have to remove them
> yourself.
Sure. Can I ask
On 8 August 2011 18:06, Avi Kivity wrote:
> Somewhat clumsy since it needs a variable sized region.
> @@ -119,7 +120,7 @@ void omap_sdrc_reset(struct omap_sdrc_s *s);
> struct omap_gpmc_s;
> struct omap_gpmc_s *omap_gpmc_init(target_phys_addr_t base, qemu_irq irq);
> void omap_gpmc_reset(struc
On 8 August 2011 13:56, Avi Kivity wrote:
> QEMU deals with a lot of fixed width integer types; their names
> (uint64_t etc) are clumsy to use and take up a lot of space.
>
> Following Linux, introduce shorter names, for example U64 for
> uint64_t.
Strongly disagree. uint64_t &c are standard type
On 25 July 2011 10:32, Alexander Graf wrote:
> On 25.07.2011, at 10:51, Avi Kivity wrote:
>> qemu_malloc() is type-unsafe as it returns a void pointer. Introduce
>> QEMU_NEW() (and QEMU_NEWZ()), which return the correct type.
>
> What does this buy you over
>
> type *x = qemu_malloc(sizeof(type))
On 5 July 2011 07:15, Markus Armbruster wrote:
>> + int fd, __attribute__((unused)) ret;
>>
>> snprintf(reset_file, sizeof(reset_file),
>> "/sys/bus/pci/devices/%04x:%02x:%02x.%01x/reset",
>
> What about (void)write() and do away with ret?
If 'ret' has been used to silence c
On 4 July 2011 23:00, Raghavendra D Prabhu wrote:
> This is to avoid gcc optimizating out the comparison in assert,
> due to assumption of signed overflow being undefined by default
> (-Werror=strict-overflow).
>--- a/Makefile.hw
>+++ b/Makefile.hw
>@@ -9,7 +9,7 @@ include $(SRC_PATH)/rules.mak
On 28 June 2011 13:09, Avi Kivity wrote:
> Okay, let's make t_p_a_t max(bus size in system).
If you want a type for that, can't you give it a sensible (ie
different) name? target_phys_addr_t is pretty clearly "the type
of a physical address for this target" and having it actually
be something els
On 15 June 2011 15:32, Richard Henderson wrote:
> On 06/15/2011 01:35 AM, Alexander Graf wrote:
>>> - abi_ulong arg5 = 0, arg6 = 0, arg7 = 0, arg8 = 0;
>>> + abi_ulong arg5 = 0, arg6 = 0;
>>>
>>> nb_args = mips_syscall_args[syscall_num];
>>>
On 15 June 2011 09:35, Alexander Graf wrote:
>
> On 14.06.2011, at 19:36, Michael S. Tsirkin wrote:
>> return 0;
>> @@ -7058,18 +7056,14 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
>> arg1,
>> case TARGET_NR_osf_sigprocmask:
>> {
>> abi_ulong mask;
>> -
; - remove bashism
Thanks; can't see any problems in this version.
Reviewed-by: Peter Maydell
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 8 June 2011 16:06, Jan Kiszka wrote:
> + if [ $arch == x86 ]; then
This should be a single '=' -- '==' is a bashism. The 'checkbashisms'
script (available in 'devscripts' package on debian and ubuntu)
catches this:
cam-vm-266:maverick:testing$ checkbashisms scripts/update-linux-headers.sh
2011/6/8 Jan Kiszka :
> On 2011-06-08 16:33, Peter Maydell wrote:
>> On 8 June 2011 15:10, Jan Kiszka wrote:
>>> +tmpdir=$TMPDIR/.tmp-hdrs-$$
>>
>> Better (safer) to use mktemp, I think.
>
> Is that portable? I don't think so.
We don't expect ev
On 8 June 2011 15:10, Jan Kiszka wrote:
> --- /dev/null
> +++ b/scripts/update-linux-headers.sh
> @@ -0,0 +1,55 @@
> +#!/bin/sh -e
> +#
> +if [ -z "$output" ]; then
> + output=$PWD
> +fi
> + mkdir -p $output/linux-headers/asm-$arch
This script is rather lacking in quoting throughout. As a
On 3 May 2011 17:48, Jan Kiszka wrote:
> +++ b/scripts/update-linux-headers.sh
> @@ -0,0 +1,47 @@
> +#!/bin/sh
No -e ?
> +rm -rf $output/include/linux/*
Given that updating the kernel headers will blow away large
subsets of include/ like this, maybe we should use a less generic
name than "inclu
On 3 May 2011 17:48, Jan Kiszka wrote:
> Kernel headers were automatically imported from current kvm.git,
> 93c016c8c4. Some are not covered by any license and can be considered
> GPLv2 with user space exception.
Hmm. Can't we just get whoever owns those files to apply a suitable
copyright and li
On 6 April 2011 20:34, Anthony Liguori wrote:
> http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/crashdump/liaaicrashdumpnmiipmi.htm
>
> If an OS is totally hosed (spinning with interrupts disabled), and NMI can
> be used to generate a crash dump.
>
> It's a debug fea
On 6 April 2011 20:00, Luiz Capitulino wrote:
> On Wed, 06 Apr 2011 20:17:47 +0200
> Jan Kiszka wrote:
>> HMP is currently x86-only, thus it's probably OK to model it after some
>> PC feature (though I don't know if there aren't NMI buttons with BP-only
>> wirings). But will the consolidate versi
On 17 February 2011 13:37, Anthony Liguori wrote:
> An application has to explicitly support an encoding. It is not
> transparent. UCS2/UTF-16 means that strings are not 'const char *'s but
> 'const wchar_t *' where typedef unsigned short wchar_t;.
>
> QEMU assumes, in lots of places that string
On 13 February 2011 22:43, Anthony Liguori wrote:
> On 02/13/2011 03:24 PM, Peter Maydell wrote:
>> How would this work for systems with multiple CPUs which have different
>> views of the world? (ie their memory maps differ so that eg some RAM is
>> shared between them
On 13 February 2011 16:56, Anthony Liguori wrote:
> If we can move away from Bus abstraction and to a simpler interface
> mechanism, then we can express peer relationships by just having bidirection
> references. IOW:
>
> -device cpus,northbridge=nb,id=cpus,count=16 -device i440fx,cpus=cpus
>
> I
On 10 February 2011 19:17, Scott Wood wrote:
> On Thu, 10 Feb 2011 08:16:15 +
> Peter Maydell wrote:
>> On 10 February 2011 07:47, Anthony Liguori wrote:
>> > So very concretely, I'm suggesting we do the following to target-i386:
>>
>> > 2)
On 10 February 2011 12:23, Anthony Liguori wrote:
> But something interacts with each processor and dispatches the I/O
> operations in the address space, no? I can't believe there are 2^32 address
> lines coming off of every arm chip that each device connects.
Well, the AXI bus is kind of compli
On 10 February 2011 10:13, Anthony Liguori wrote:
> On 02/10/2011 10:04 AM, Peter Maydell wrote:
>>
>> On 10 February 2011 08:36, Anthony Liguori wrote:
>>> So you would model arm926ej-s as the chipset and then build up the
>>> machines
>>> by modifying
On 10 February 2011 08:36, Anthony Liguori wrote:
> On 02/10/2011 09:16 AM, Peter Maydell wrote:
>> On 10 February 2011 07:47, Anthony Liguori wrote:
>>> 2) get rid of the entire concept of machines. Creating a i440fx is
>>> essentially equivalent to creating a ba
On 10 February 2011 07:47, Anthony Liguori wrote:
> So very concretely, I'm suggesting we do the following to target-i386:
> 2) get rid of the entire concept of machines. Creating a i440fx is
> essentially equivalent to creating a bare machine.
Does that make any sense for anything other than t
On 9 February 2011 08:11, Markus Armbruster wrote:
> Peter Maydell writes:
>> Markus Armbruster wrote:
>>> I've said this before: at some point in time (sooner rather than
>>> later, if you ask me), we need to shoot the stragglers.
>> ...and my question
On 8 February 2011 17:13, Markus Armbruster wrote:
> As far as qdev's concerned, I can see two kinds of to-dos:
>
> * Further develop qdev so that more of the machine init code can becomes
> qdev declarations. Specific ideas welcome. Patches even more, as
> always.
>
> * Convert the remaining
On 10 January 2011 07:45, Stefan Hajnoczi wrote:
> On Mon, Jan 10, 2011 at 1:05 PM, Jes Sorensen wrote:
>> Just to add a bit more background. Last year we discussed the issue of
>> whether to aim for a KVM Forum in the same style as we had in 2010, or
>> whether to try to aim for a broader multi-
501 - 540 of 540 matches
Mail list logo
