On 11/27/2011 02:26 PM, Juan Quintela wrote:
This is the reason that I started with:
- Add myself as a copyright owner
- Put the original authors as: Based on previous work from: John Smith.
I would just put Copyright (C) - The QEMU Contributors. For a
full list, there is always the
On Sun, Nov 27, 2011 at 6:50 PM, Gleb Natapov wrote:
> On Sun, Nov 27, 2011 at 12:36:55PM +0200, Avi Kivity wrote:
>> On 11/27/2011 04:42 AM, Liu Ping Fan wrote:
>> > From: Liu Ping Fan
>> >
>> > The vcpu can be safely released when
>> > --1.guest tells us that the vcpu is not needed any longer.
>From 8bb5d052825149c211afa92458912bc49a50ee2f Mon Sep 17 00:00:00 2001
From: Liu, Jinsong
Date: Mon, 28 Nov 2011 03:55:19 -0800
Subject: [PATCH] X86: expose latest Intel cpu new features to guest
Intel latest cpu add 6 new features, refer http://software.intel.com/file/36945
The new feature cpui
We find that the "new_base" doesn't change during in the following loop, so we
can outer this judgement from this loop.
Signed-off-by: Wanghuang
diff --git a/qemu/tcg/optimize.c b/qemu-local/tcg/optimize.c
index 9c65474..27164f0 100644
--- a/qemu/tcg/optimize.c
+++ b/qemu-local/tcg/optimize.
On Fri, Nov 04, 2011 at 11:49:26AM +0100, Andreas Färber wrote:
> Am 04.11.2011 02:03, schrieb David Gibson:
> > As a few people pointed out, my recent patch series introducing a new
> > (stub) PCI DMA API added unnecessary casts in quite a few places. I
> > think this was a hangover from early da
Ahh, I got it!
Thanks.
2011/11/25 Paolo Bonzini
> On 11/25/2011 08:26 AM, Mark Wu wrote:
>
>> 1. This patch aims to add 4k logical support for qemu running on a host
>> with 4k logical block size, right?
>>
>
> No, it adds support for 512b logical block sizes running on a host with 4k
> logical
If a pflash image is found, then it is used for the system
firmware image.
If a pflash image is not initially found, then a read-only
pflash device is created using the -bios filename.
KVM cannot execute from a pflash region currently.
Therefore, when KVM is enabled, a (read-only) ram memory
regi
When read-only mode is enabled, no changes will be made
to the flash image in memory, and no bdrv_write calls will be
made.
For pflash_cfi01 (Intel), if the flash is in read-only mode
then the status register will signal block erase error or
program error when these operations are attempted.
For
Enable flash emulation in a PC system using pflash_cfi01.
v8:
* Cleanup two chunks of debug code (printf messages)
* Fix comment in pc.h (pcflash.c => pc_sysfw.c)
v7:
* Do not add system firmware to qemu roms
* If kvm is enabled, copy pflash drive contents into a
read-only ram region, since kvm
Any comment?
Thanks.
2011/11/15 Dong Xu Wang
> From: Dong Xu Wang
>
> Provide a new file format: add-cow. The usage can be found in add-cow.txt
> of
> this patch.
>
> Signed-off-by: Dong Xu Wang
> ---
> Makefile.objs |1 +
> block.c|2 +-
> block.h
one more question. I was going through this code here. the lines in bold
are what happened when the second operand of the operation is a memory
location. what is the IS_DEAD_ARG(1), is the register allocator doing some
liveness analysis here ?
static void tcg_reg_alloc_mov(TCGContext *s, const TC
Thank you very much. This is very helpful.
Xin
On Sun, Nov 27, 2011 at 6:33 PM, Peter Maydell wrote:
> On 27 November 2011 23:07, Xin Tong wrote:
>> can you please show me where the (120) is used. we pushed a global
>> TCGV to the gen_opparam_ptr. lets say the backend is i386 and the
>> operat
On 27 November 2011 23:07, Xin Tong wrote:
> can you please show me where the (120) is used. we pushed a global
> TCGV to the gen_opparam_ptr. lets say the backend is i386 and the
> operation is an add.
So, you can find it like this:
(1) starting from tcg_global_mem_new_i64 we follow where that
can you please show me where the (120) is used. we pushed a global
TCGV to the gen_opparam_ptr. lets say the backend is i386 and the
operation is an add.
Thanks
Xin
On Sun, Nov 27, 2011 at 3:59 PM, Peter Maydell wrote:
> On 27 November 2011 16:17, Xin Tong wrote:
>> So the offset value (120)
Peter Feiner wrote:
> Enables providing a backing file for the PC's ram. The file is specified by
> the
> new -pcram-file option. The file is mmap'd shared, so the RAMBlock that it
> backs
> doesn't need to be saved by vm_save / migration.
>
> Signed-off-by: Peter Feiner
Hi
Do you have any pe
Am 27.11.2011 15:17, schrieb Avi Kivity:
> On 11/27/2011 04:07 PM, Andreas Färber wrote:
>> Thanks a lot! You were right, setting TARGET_PAGE_BITS to 8 solves this
>> issue.
>>
>> I'd still like to fix this subpage case for others' benefit. Do you have
>> any pointer where I should set breakpoints
On 27 November 2011 16:17, Xin Tong wrote:
> So the offset value (120) is really encapsulated in the TCGv
> structure. and when we need the offset, we just call GET_TCGV_IA64
> like what it is doing here
>
> static inline void tcg_gen_op3_i64(TCGOpcode opc, TCGv_i64 arg1, TCGv_i64
> arg2,
>
On 11/27/2011 07:04 AM, Avi Kivity wrote:
On 11/24/2011 08:03 PM, Luiz Capitulino wrote:
Avi,
I'm getting the following panic very early on boot on a F16 VM (latest
qemu.git head 40897c9):
[0.068018] Kernel panic - not syncing: Boot APIC ID in local APIC
unexpected (-1 vs 0)
[0.070006
So the offset value (120) is really encapsulated in the TCGv
structure. and when we need the offset, we just call GET_TCGV_IA64
like what it is doing here
static inline void tcg_gen_op3_i64(TCGOpcode opc, TCGv_i64 arg1, TCGv_i64 arg2,
TCGv_i64 arg3)
{
*gen_o
Am 27.11.2011 16:23, schrieb Xin Tong:
> This is a bit confusing then
>
> in target-i386/translate.c
>
> void optimize_flags_init(void)
> {
> ...
> cpu_regs[15] = tcg_global_mem_new_i64(TCG_AREG0,
> offsetof(CPUState, regs[15]),
> "r15");
> printf(
On 27 November 2011 15:23, Xin Tong wrote:
> cpu_regs[15] = tcg_global_mem_new_i64(TCG_AREG0,
> offsetof(CPUState, regs[15]), "r15");
> printf("offsetof(CPUState, regs[15]) is %ld\n", offsetof(CPUState,
> regs[15]));
> output is cpu_regs[15] is 20, offs
This is a bit confusing then
in target-i386/translate.c
void optimize_flags_init(void)
{
...
cpu_regs[15] = tcg_global_mem_new_i64(TCG_AREG0,
offsetof(CPUState, regs[15]), "r15");
printf("offsetof(CPUState, regs[15]) is %ld\n", offsetof(CPUState, re
Am 27.11.2011 15:36, schrieb Xin Tong:
> If i understand correctly here, those are just array of offsets for
> the emulated registers such that the tcg can easily get access to the
> address of the emulated registers. This is, however, different from
> the env (CPUx86State) variable which will alwa
Andreas,
Thank you. I guess I'll go back to Bochs. Things are simpler there. :-)
I do appreciate your help.
Thanks and best regards,
Rick C. Hodgin
--- On Sun, 11/27/11, Andreas Färber wrote:
> From: Andreas Färber
> Subject: Re: [Qemu-devel] Add native debugger
> To: "Rick Hodgin"
> Cc:
If i understand correctly here, those are just array of offsets for
the emulated registers such that the tcg can easily get access to the
address of the emulated registers. This is, however, different from
the env (CPUx86State) variable which will always have a host register
pointing to it ( host r
Am 27.11.2011 15:12, schrieb Rick Hodgin:
> --- On Sun, 11/27/11, Blue Swirl wrote:
>> On Sun, Nov 27, 2011 at 04:10, Rick
>> Hodgin
>> wrote:
>>> For i386, I'm considering writing a native debugger
>> for QEMU that is not GDB. It would allow a separate/new
>> windowed interface which would show
On 11/27/2011 04:07 PM, Andreas Färber wrote:
> Thanks a lot! You were right, setting TARGET_PAGE_BITS to 8 solves this
> issue.
>
> I'd still like to fix this subpage case for others' benefit. Do you have
> any pointer where I should set breakpoints / review code?
The subpage code (scheduled for
Am 27.11.2011 14:46, schrieb Xin Tong:
> When the x86 vcpu is initialized, a CPUX86State is qemu_mallocz'ed.
> env is used to point to it and modifications to the CPUX86State can
> thereby be done via the register that contains the env. I do not get
> what the cpu_regs[CPU_NB_REGS] are for, do not
Blue,
--- On Sun, 11/27/11, Blue Swirl wrote:
> On Sun, Nov 27, 2011 at 04:10, Rick
> Hodgin
> wrote:
> > For i386, I'm considering writing a native debugger
> for QEMU that is not GDB. It would allow a separate/new
> windowed interface which would show disassembly, registers,
> stack, local v
Am 27.11.2011 09:32, schrieb Avi Kivity:
> On 11/25/2011 06:25 PM, Andreas Färber wrote:
>> Am 24.11.2011 00:59, schrieb Andreas Färber:
>>> Unlike PowerPC, an architecture that I'm trying to emulate does not
>>> store branch instructions in the reset vector but a memory address. I'm
>>> therefore
When the x86 vcpu is initialized, a CPUX86State is qemu_mallocz'ed.
env is used to point to it and modifications to the CPUX86State can
thereby be done via the register that contains the env. I do not get
what the cpu_regs[CPU_NB_REGS] are for, do not we already have a set
of emulated x86 registers
Andreas Färber wrote:
> Hi Juan,
>
> Am 23.11.2011 16:44, schrieb Juan Quintela:
>> [ Resnd this time also ading fabrice address, sorry ]
>>
>> v2:
>> - split patches by file, make easier to add "acked-by" notices.
>> - cc'd fabrice
>> - everybody (except for Thiemo for ovbious reasons) answered.
Blue Swirl wrote:
> On Wed, Nov 23, 2011 at 15:44, Juan Quintela wrote:
>> v2: Move license to BSD-like as in vl.c
>
> This does not belong to the commit message.
>
>> Signed-off-by: Juan Quintela
>> ---
>> target-sparc/vmstate-cpu.c | 29 +
>> 1 files changed, 29
On 11/24/2011 08:03 PM, Luiz Capitulino wrote:
> Avi,
>
> I'm getting the following panic very early on boot on a F16 VM (latest
> qemu.git head 40897c9):
>
> [0.068018] Kernel panic - not syncing: Boot APIC ID in local APIC
> unexpected (-1 vs 0)
> [0.070006] Pid: 1, comm: swapper Not tai
On Sun, Nov 27, 2011 at 04:10, Rick Hodgin wrote:
> For i386, I'm considering writing a native debugger for QEMU that is not GDB.
> It would allow a separate/new windowed interface which would show
> disassembly, registers, stack, local variables, memory windows, etc.,
> allowing the user to si
On 11/25/2011 12:07 PM, Daniel P. Berrange wrote:
On Thu, Nov 24, 2011 at 02:40:07PM +0200, Dor Laor wrote:
On 11/17/2011 09:58 PM, Michael Roth wrote:
On 11/17/2011 10:34 AM, Barak Azulay wrote:
On Thursday 17 November 2011 02:48:50 Michael Roth wrote:
I've tried to summarize the pros/cons,
On Sat, Nov 26, 2011 at 13:19, Greg Stevn wrote:
> Is there virtualization method for sparc on linux?
KVM for Sparc does not exist, it would need some effort from both
QEMU(-kvm) and kernel side.
Sparc is in theory not as ugly as x86 in this area, user space has
been cleanly separated from privi
On Sun, Nov 27, 2011 at 10:47:43AM +0800, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> A driver for qemu device "cpustate". This driver catch the guest
> CPU_DEAD event, and notify host.
>
And if you do eject properly via ACPI this driver is replaced by 3 lines
of ACPI code and works with older
On Sun, Nov 27, 2011 at 10:45:35AM +0800, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> This device's driver in guest can get vcpu dead event and notify
> qemu through the device.
>
This should be done through ACPI device. Look at how PCI hotplug works
in hw/acpi_piix4.c.
> Signed-off-by: Liu Pi
On Sun, Nov 27, 2011 at 12:36:55PM +0200, Avi Kivity wrote:
> On 11/27/2011 04:42 AM, Liu Ping Fan wrote:
> > From: Liu Ping Fan
> >
> > The vcpu can be safely released when
> > --1.guest tells us that the vcpu is not needed any longer.
> > --2.vcpu hits the last instruction _halt_
> >
> > If both
On 11/27/2011 04:42 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> The vcpu can be safely released when
> --1.guest tells us that the vcpu is not needed any longer.
> --2.vcpu hits the last instruction _halt_
>
> If both of the conditions are satisfied, kvm exits to userspace
> with the reason v
On 11/25/2011 04:35 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> Currently, vcpu can be destructed only when kvm instance destroyed.
> Change this to vcpu as a refer to kvm, and then vcpu MUST and CAN be
> destroyed before kvm's destroy. Qemu will take advantage of this to
> exit the vcpu thre
On 11/25/2011 04:21 PM, Benoît Canet wrote:
> Signed-off-by: Benoît Canet
> ---
> hw/omap_sx1.c | 113
> ++---
> 1 files changed, 59 insertions(+), 54 deletions(-)
>
> diff --git a/hw/omap_sx1.c b/hw/omap_sx1.c
> index fe53545..b056bc9 100644
On 11/27/2011 01:24 AM, Ronnie Sahlberg wrote:
> This patch adds configuration variables for iSCSI to set
> initiator-name to use when logging in to the target,
> which type of header-digest to negotiate with the target
> and username and password for CHAP authentication.
>
> This allows specifyin
On 11/24/2011 03:31 PM, Benoît Canet wrote:
> These patches convert some files to memory API
>
Thanks, applied.
--
error compiling committee.c: too many arguments to function
On 11/25/2011 09:01 AM, Stefan Weil wrote:
>
> Boards normally have state structures, the device model
> supports this and is not wrong here.
>
> The Malta implementation simply needs conversion to qdev.
> This is something which will be done after QEMU 1.0.
>
> My patch is not the final solution.
On 11/25/2011 06:25 PM, Andreas Färber wrote:
> Am 24.11.2011 00:59, schrieb Andreas Färber:
> > Unlike PowerPC, an architecture that I'm trying to emulate does not
> > store branch instructions in the reset vector but a memory address. I'm
> > therefore trying to read physical address 0x0 and
47 matches
Mail list logo
