On Fri, Mar 31, 2017 at 09:20:31PM +0300, Mihai-Drosi Caju wrote:
> I'd be interested in submitting the following ideas:
> I'd like to enchance qemu's debugging capabilities.
> I was thinking to add an option to qemu to disable cpu reset on
> tripple-fault.
> Or adding support for breakpoints in
Good day,
I'd be interested in submitting the following ideas:
I'd like to enchance qemu's debugging capabilities.
I was thinking to add an option to qemu to disable cpu reset on
tripple-fault.
Or adding support for breakpoints in the GDB stub while using kvm or
another accelerator.
Or emulating a
On Mon, 6 Jan 2014, Peter Maydell wrote:
On 6 January 2014 17:34, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Mon, 6 Jan 2014, Peter Maydell wrote:
However I don't think we can have a qemu-system-null
(regardless of use cases) until/unless we get rid of
all the things
On 7 January 2014 13:26, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Mon, 6 Jan 2014, Peter Maydell wrote:
The identifiers poisoned by include/qemu/poison.h are
an initial but not complete list. Host and target
endianness is a particularly obvious one, as is the
size of a
Il 07/01/2014 14:26, Stefano Stabellini ha scritto:
The identifiers poisoned by include/qemu/poison.h are
an initial but not complete list. Host and target
endianness is a particularly obvious one, as is the
size of a target long. You may not use these things
in your Xen devices, but
On Tue, 7 Jan 2014, Paolo Bonzini wrote:
Il 07/01/2014 14:26, Stefano Stabellini ha scritto:
The identifiers poisoned by include/qemu/poison.h are
an initial but not complete list. Host and target
endianness is a particularly obvious one, as is the
size of a target long. You may not
On Tue, Jan 07, 2014 at 02:50:12PM +0100, Paolo Bonzini wrote:
Il 07/01/2014 14:26, Stefano Stabellini ha scritto:
The identifiers poisoned by include/qemu/poison.h are
an initial but not complete list. Host and target
endianness is a particularly obvious one, as is the
size of a
Il 07/01/2014 15:38, Wei Liu ha scritto:
On Tue, Jan 07, 2014 at 02:50:12PM +0100, Paolo Bonzini wrote:
Il 07/01/2014 14:26, Stefano Stabellini ha scritto:
The identifiers poisoned by include/qemu/poison.h are
an initial but not complete list. Host and target
endianness is a particularly
On 7 January 2014 13:50, Paolo Bonzini pbonz...@redhat.com wrote:
So let's call things by their name and add qemu-system-xenpv that covers
both x86 and ARM and anything else in the future.
How is this going to work? Do you define a fake architecture
name xenpv ? I guess we'll see what the
Il 07/01/2014 16:11, Peter Maydell ha scritto:
So let's call things by their name and add qemu-system-xenpv that covers
both x86 and ARM and anything else in the future.
How is this going to work? Do you define a fake architecture
name xenpv ?
Yes, one that aborts if a CPU is created or
Hi all
This idea is to modify QEMU's Makefiles, plus implementing some stubs to
make it possible to tailor QEMU to a smaller binary.
The current setup for Xen on X86 is to build i386-softmmu, and uses this
single binary for two purposes:
1. serves as device emulator for HVM guest.
2. serves as
On Mon, Jan 6, 2014 at 10:54 PM, Wei Liu wei.l...@citrix.com wrote:
Hi all
This idea is to modify QEMU's Makefiles, plus implementing some stubs to
make it possible to tailor QEMU to a smaller binary.
The current setup for Xen on X86 is to build i386-softmmu, and uses this
single binary for
On 6 January 2014 12:54, Wei Liu wei.l...@citrix.com wrote:
In fact I've already hacked a prototype during Christmas. What's I've
done so far:
1. create target-null which only has some stubs to CPU emulation
framework.
2. add a few lines to configure / Makefiles*, create
On Mon, Jan 06, 2014 at 11:23:24PM +1000, Peter Crosthwaite wrote:
[...]
Down to implementation level I only need to (hopefully) add a few stubs
and create some new CONFIG_* options and move a few things around. It
might not be as intrusive as one thinks.
In fact I've already hacked a
On 6 January 2014 15:11, Wei Liu wei.l...@citrix.com wrote:
On Mon, Jan 06, 2014 at 11:23:24PM +1000, Peter Crosthwaite wrote:
[...]
Finally I got a qemu-system-null. And the effect is immediately visible
qemu-system-null has been on my wish-list in the past, although my
reasons were
On Mon, 6 Jan 2014, Peter Maydell wrote:
On 6 January 2014 15:11, Wei Liu wei.l...@citrix.com wrote:
On Mon, Jan 06, 2014 at 11:23:24PM +1000, Peter Crosthwaite wrote:
[...]
Finally I got a qemu-system-null. And the effect is immediately visible
qemu-system-null has been on my
On 6 January 2014 17:34, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Mon, 6 Jan 2014, Peter Maydell wrote:
However I don't think we can have a qemu-system-null
(regardless of use cases) until/unless we get rid of
all the things which are compile-time decided by
the system
Am 06.01.2014 16:12, schrieb Wei Liu:
On Mon, Jan 06, 2014 at 01:30:20PM +, Peter Maydell wrote:
On 6 January 2014 12:54, Wei Liu wei.l...@citrix.com wrote:
In fact I've already hacked a prototype during Christmas. What's I've
done so far:
1. create target-null which only has some stubs
On Mon, Jan 06, 2014 at 07:12:07PM +0100, Andreas Färber wrote:
Am 06.01.2014 16:12, schrieb Wei Liu:
On Mon, Jan 06, 2014 at 01:30:20PM +, Peter Maydell wrote:
On 6 January 2014 12:54, Wei Liu wei.l...@citrix.com wrote:
In fact I've already hacked a prototype during Christmas. What's
19 matches
Mail list logo
