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 th
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
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 creat
On 7 January 2014 13:50, Paolo Bonzini 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 patches look like...
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 par
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
> > > si
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. Y
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
On 7 January 2014 13:26, Stefano Stabellini
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 target long. You may not u
On Mon, 6 Jan 2014, Peter Maydell wrote:
> On 6 January 2014 17:34, Stefano Stabellini
> 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-tim
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 wrote:
> >>> In fact I've already hacked a prototype during Christmas. What's I've
> >>>
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 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 CP
On 6 January 2014 17:34, Stefano Stabellini
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 config. In an ideal world
On Mon, 6 Jan 2014, Peter Maydell wrote:
> On 6 January 2014 15:11, Wei Liu 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-l
On 6 January 2014 15:11, Wei Liu 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 slightly d
On Mon, Jan 06, 2014 at 01:30:20PM +, Peter Maydell wrote:
> On 6 January 2014 12:54, Wei Liu 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.
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 alread
On 6 January 2014 12:54, Wei Liu 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
>default-configs/null-sof
On Mon, Jan 6, 2014 at 10:54 PM, Wei Liu 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 two purposes
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 PV
20 matches
Mail list logo
