historically the kernel queues packets two times. once
at the device and second in qdisc. this is believed to cause
interface stalls if one of these queues overruns.
setting IFF_ONE_QUEUE is the default in kernels >= 3.8. the
flag is ignored since then. see kernel commit
5d097109257c03a71845729f8
Il 15/02/2013 03:49, Antoine Mathys ha scritto:
> First, the ds1338 code was in a poor state and never handled the 12 hour
> clock correctly. My first patch failed to fully fix the problem so I had
> to write a second one, but at no point did Peter or I introduce a
> regression, quite the opposite.
On Thu, Feb 14, 2013 at 04:40:29PM +0100, Andreas Färber wrote:
> CC'ing some more people from the "debug output revamp" RFC discussion.
>
> Am 11.02.2013 20:01, schrieb Andreas Färber:
> > From: Andreas Färber
> >
> > Signed-off-by: Andreas Färber
> > ---
> > hw/tmp105.c | 27 ++
Il 15/02/2013 04:56, Tomoki Sekiyama ha scritto:
>
>> > Now, is using C++ required? Why can't you use plain C?
> It is because Windows COM+ framework (which VSS uses) is designed based
> on C++ objective programming interface. Implementing this with plain C
> is theoretically possible, but that wi
On Thu, Feb 14, 2013 at 07:15:03PM +0200, Michael S. Tsirkin wrote:
> QEMU 1.3 does not emulate the link auto negotiation, so if migrate to a
> 1.3 machine during link auto negotiation, the guest link will be set to down.
> Fix this by just disabling auto negotiation for 1.3.
>
> Signed-off-by: Mi
On Thu, Feb 14, 2013 at 04:45:06PM +0100, Kevin Wolf wrote:
> On Thu, Feb 14, 2013 at 03:48:51PM +0100, Stefan Hajnoczi wrote:
> > On Wed, Feb 13, 2013 at 02:21:53PM +0100, Kevin Wolf wrote:
> > > + *
> > > + * -EAGAIN if we had to wait for another request, previously gathered
> > > + *
On Fri, Feb 15, 2013 at 09:27:18AM +0100, Peter Lieven wrote:
> historically the kernel queues packets two times. once
> at the device and second in qdisc. this is believed to cause
> interface stalls if one of these queues overruns.
>
> setting IFF_ONE_QUEUE is the default in kernels >= 3.8. the
Am 15.02.2013 um 10:16 schrieb Stefan Hajnoczi :
> On Fri, Feb 15, 2013 at 09:27:18AM +0100, Peter Lieven wrote:
>> historically the kernel queues packets two times. once
>> at the device and second in qdisc. this is believed to cause
>> interface stalls if one of these queues overruns.
>>
>> se
On 15/02/13 09:27, Peter Lieven wrote:
> historically the kernel queues packets two times. once
> at the device and second in qdisc. this is believed to cause
> interface stalls if one of these queues overruns.
>
> setting IFF_ONE_QUEUE is the default in kernels >= 3.8. the
> flag is ignored since
On 15/02/13 10:25, Peter Lieven wrote:
>
> Am 15.02.2013 um 10:22 schrieb Christian Borntraeger :
>
>> On 15/02/13 09:27, Peter Lieven wrote:
>>> historically the kernel queues packets two times. once
>>> at the device and second in qdisc. this is believed to cause
>>> interface stalls if one of
On Thu, Feb 14, 2013 at 02:57:34PM -0600, Anthony Liguori wrote:
> Hi,
>
> On behalf of the QEMU Team, I'd like to announce the availability of the
> third release candidate for the QEMU 1.4 release. This release is meant
> for testing purposes and should not be used in a production environment.
historically the kernel queues packets two times. once
at the device and second in qdisc. this is believed to cause
interface stalls if one of these queues overruns.
setting IFF_ONE_QUEUE is the default in kernels >= 3.8. the
flag is ignored since then. see kernel commit
5d097109257c03a71845729f8
Am 15.02.2013 um 10:22 schrieb Christian Borntraeger :
> On 15/02/13 09:27, Peter Lieven wrote:
>> historically the kernel queues packets two times. once
>> at the device and second in qdisc. this is believed to cause
>> interface stalls if one of these queues overruns.
>>
>> setting IFF_ONE_QUE
On Thu, Feb 14, 2013 at 09:40:22PM +, Blue Swirl wrote:
> On Thu, Feb 14, 2013 at 9:40 AM, Kevin Wolf wrote:
> > Am 13.02.2013 22:17, schrieb Blue Swirl:
> >> On Wed, Feb 13, 2013 at 1:22 PM, Kevin Wolf wrote:
> >>> Look only for clusters that start at a given physical offset.
> >>>
> >>> Sig
Am 15.02.2013 10:06, schrieb Stefan Hajnoczi:
> In iPXE they use a clever compile-time debug macro:
> https://git.ipxe.org/ipxe.git/blob/HEAD:/src/include/compiler.h#l204
>
> Basically you do DBG("hello world\n") and it gets compiled out by
> default using:
> if (DBG_LOG) {
> printf("hello
On Thu, Feb 14, 2013 at 07:21:57PM +0100, Luigi Rizzo wrote:
CCed Michael Tsirkin
> virtio-style network devices (where the producer and consumer chase
> each other through a shared memory block) can enter into a
> bad operating regime when the consumer is too fast.
>
> I am hitting this case ri
On Fri, 2013-02-15 at 11:19 +0400, Michael Tokarev wrote:
> This patch is more than 2 years old and is applied to all more or
> less recent qemu versions.
RHEL 6.3?
I'm *not* seeing this bug with recent qemu versions.
> This does not tell us why disabling kvm (with this patch applied!)
> makes
From: Erlon Cruz
This h_call is useful for DLPAR in future amongst other things. Given an index
it fetches the corresponding PTE stored in the htab.
Signed-off-by: Erlon Cruz
---
hw/spapr_hcall.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/hw/spapr
this patch adds iscsi_truncate which effectively allows for online
resizing of iscsi volumes. for this to work you have to resize
the volume on your storage and then call block_resize command
in qemu which will issue a readcapacity16 to update the capacity.
Signed-off-by: Peter Lieven
---
block
Il 15/02/2013 11:58, Peter Lieven ha scritto:
> this patch adds iscsi_truncate which effectively allows for online
> resizing of iscsi volumes. for this to work you have to resize
> the volume on your storage and then call block_resize command
> in qemu which will issue a readcapacity16 to update t
On 15.02.2013 12:09, Paolo Bonzini wrote:
Il 15/02/2013 11:58, Peter Lieven ha scritto:
this patch adds iscsi_truncate which effectively allows for online
resizing of iscsi volumes. for this to work you have to resize
the volume on your storage and then call block_resize command
in qemu which wi
Antoine,
Am 15.02.2013 03:49, schrieb Antoine Mathys:
> First, the ds1338 code was in a poor state and never handled the 12 hour
> clock correctly. My first patch failed to fully fix the problem so I had
> to write a second one, but at no point did Peter or I introduce a
> regression, quite the op
A socket may still have references to it in various queues
at the time it is freed, causing memory corruptions.
Signed-off-by: Vitaly Chipounov
---
slirp/socket.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/slirp/socket.c b/slirp/socket.c
index 77b0c98..8
On 15 February 2013 11:24, Andreas Färber wrote:
> Am 15.02.2013 03:49, schrieb Antoine Mathys:
>> First, the ds1338 code was in a poor state and never handled the 12 hour
>> clock correctly. My first patch failed to fully fix the problem so I had
>> to write a second one, but at no point did Pete
Make the SysBusDeviceClass::init optional, for devices which
genuinely don't need to do anything here. In particular, simple
devices which can do all their initialization in their
instance_init method don't need either a DeviceClass::realize
or SysBusDeviceClass::init method.
Signed-off-by: Peter
The functions sysbus_add_memory and sysbus_del_memory are odd wrappers
around around memory_region_add/del_subregion, and their presence
is an encouragement to devices to try to map their own memory
regions into the system address space.
Since they're only used in a couple of places in the milkymi
On Thu, 14 Feb 2013 17:56:58 -0200
Eduardo Habkost wrote:
> On Thu, Feb 14, 2013 at 08:16:32PM +0100, Igor Mammedov wrote:
> > > [...]
> > > > > > +
> > > > > > +}
> > > > > > +
> > > > > > +static void x86_cpu_def_class_init(ObjectClass *oc, void *data)
> > > > > > +{
> > > > > > +X86CPUClas
Il 15/02/2013 12:18, Peter Lieven ha scritto:
>>>
>>> +task = iscsi_readcapacity16_task(iscsilun->iscsi, iscsilun->lun,
>>> + iscsi_readcapacity16_cb, &itask);
>>
>> You can use iscsi_readcapacity16_sync. In fact, you probably should
>> extract code from iscsi_o
Am 15.02.2013 um 12:54 schrieb Paolo Bonzini :
> Il 15/02/2013 12:18, Peter Lieven ha scritto:
+task = iscsi_readcapacity16_task(iscsilun->iscsi, iscsilun->lun,
+ iscsi_readcapacity16_cb, &itask);
>>>
>>> You can use iscsi_readcapacity16_sync.
On 15.02.2013, at 11:59, Erlon Cruz wrote:
> From: Erlon Cruz
>
> This h_call is useful for DLPAR in future amongst other things. Given an index
> it fetches the corresponding PTE stored in the htab.
>
> Signed-off-by: Erlon Cruz
Looks good to me, but I'd like an ack from David.
Alex
> --
Remove the sysbus_add_memory and sysbus_del_memory functions. These
are trivial wrappers for mapping a memory region into the system
memory space, and have no users now. Sysbus devices should never map
their own memory regions anyway; the correct API for mapping an mmio
region is for the creator o
Make musicpal-misc into its own (trivial) qdev device, so we
can get rid of the abuse of sysbus_add_memory().
Signed-off-by: Peter Maydell
---
hw/musicpal.c | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/hw/musicpal.c b/hw/musicpal.c
ind
On Fri, Feb 15, 2013 at 12:54:51PM +0100, Paolo Bonzini wrote:
> Il 15/02/2013 12:18, Peter Lieven ha scritto:
> >>>
> >>> +task = iscsi_readcapacity16_task(iscsilun->iscsi, iscsilun->lun,
> >>> + iscsi_readcapacity16_cb, &itask);
> >>
> >> You can use iscsi_read
Don't map the pmem and dmem RAM memory regions in the milkymist-softusb
device itself. Instead just expose them as sysbus mmio regions which
the device creator can map appropriately. This allows us to drop the
pmem_base and dmem_base properties. Instead of going via
cpu_physical_memory_read/_write
Just expose the register buffers memory as a standard sysbus mmio
region which the creator of the device can map, rather than
providing a qdev property which the creator has to set to the
base address and then doing the mapping in the device's own
init function.
Signed-off-by: Peter Maydell
---
I'm happy because the replies are getting shorter! :-)
(But I'm unhappy because my questions about QOM design requirements are
not being answered yet.)
On Fri, Feb 15, 2013 at 12:49:46PM +0100, Igor Mammedov wrote:
> On Thu, 14 Feb 2013 17:56:58 -0200
> Eduardo Habkost wrote:
>
> > On Thu, F
Am 15.02.2013 um 13:18 schrieb Kevin Wolf :
> On Fri, Feb 15, 2013 at 12:54:51PM +0100, Paolo Bonzini wrote:
>> Il 15/02/2013 12:18, Peter Lieven ha scritto:
>
> +task = iscsi_readcapacity16_task(iscsilun->iscsi, iscsilun->lun,
> + iscsi_readcapaci
Am 15.02.2013 12:45, schrieb Peter Maydell:
> Make the SysBusDeviceClass::init optional, for devices which
> genuinely don't need to do anything here. In particular, simple
> devices which can do all their initialization in their
> instance_init method don't need either a DeviceClass::realize
> or
Hi,
This is an attempt to summarize my main question from the thread:
Re: [Qemu-devel] [RFC v5] target-i386: Slim conversion to X86CPU subclasses +
KVM subclasses
My main unanswered question is about the "stability" expectations of the
introspectable class data (especially property defaults).
Il 15/02/2013 13:36, Peter Lieven ha scritto:
>>> >> Ah, I thought qmp_block_resize did a bdrv_drain_all before calling
>>> >> bdrv_truncate.
>>> >>
>>> >> Maybe it should. Kevin, what do you think?
>> >
>> > Probably. bdrv_truncate() invalidates the bdrv_check_request() result for
>> > in-fligh
Hi all,
I've just updated my QEMU git pull to master in order to do some
testing, and I'm noticing a regression with 32-bit framebuffers on PPC.
If I load QEMU with the following command line to force a 32-bit
framebuffer then the light yellow OpenBIOS background now appears as a
bright gari
Am 15.02.2013 13:51, schrieb Stefan Hajnoczi:
> On Fri, Feb 15, 2013 at 10:50:16AM +0100, Andreas Färber wrote:
>> Am 15.02.2013 10:06, schrieb Stefan Hajnoczi:
>>> In iPXE they use a clever compile-time debug macro:
>>> https://git.ipxe.org/ipxe.git/blob/HEAD:/src/include/compiler.h#l204
>>>
>>> B
From: Andreas Färber
In order to instantiate a CPU subtype we will need to know which type,
so move the cpu_model splitting into cpu_x86_init().
Parameters need to be set on the X86CPU instance, so move
cpu_x86_parse_featurestr() into cpu_x86_init() as well.
This leaves cpu_x86_register() opera
On 15.02.2013, at 14:01, Mark Cave-Ayland wrote:
> Hi all,
>
> I've just updated my QEMU git pull to master in order to do some testing, and
> I'm noticing a regression with 32-bit framebuffers on PPC.
>
> If I load QEMU with the following command line to force a 32-bit framebuffer
> then the
Am 15.02.2013 12:45, schrieb Peter Maydell:
> Make musicpal-misc into its own (trivial) qdev device, so we
> can get rid of the abuse of sysbus_add_memory().
>
> Signed-off-by: Peter Maydell
> ---
> hw/musicpal.c | 34 +-
> 1 file changed, 29 insertions(+), 5 de
On 15.02.2013, at 14:04, Andreas Färber wrote:
> Am 15.02.2013 13:51, schrieb Stefan Hajnoczi:
>> On Fri, Feb 15, 2013 at 10:50:16AM +0100, Andreas Färber wrote:
>>> Am 15.02.2013 10:06, schrieb Stefan Hajnoczi:
In iPXE they use a clever compile-time debug macro:
https://git.ipxe.org/ip
Am 15.02.2013 12:45, schrieb Peter Maydell:
> Just expose the register buffers memory as a standard sysbus mmio
> region which the creator of the device can map, rather than
> providing a qdev property which the creator has to set to the
> base address and then doing the mapping in the device's own
(removing edk2-devel, adding Jan)
On 02/15/13 08:19, Michael Tokarev wrote:
> 15.02.2013 07:43, Kevin O'Connor wrote:
>> On Fri, Feb 15, 2013 at 04:10:59AM +0100, Laszlo Ersek wrote:
>>> On 02/15/13 02:22, Kevin O'Connor wrote:
On Thu, Feb 14, 2013 at 08:16:02PM -0500, Kevin O'Connor wrote:
>
Am 15.02.2013 12:45, schrieb Peter Maydell:
> Don't map the pmem and dmem RAM memory regions in the milkymist-softusb
> device itself. Instead just expose them as sysbus mmio regions which
> the device creator can map appropriately. This allows us to drop the
> pmem_base and dmem_base properties. I
Am 15.02.2013 12:45, schrieb Peter Maydell:
> Remove the sysbus_add_memory and sysbus_del_memory functions. These
> are trivial wrappers for mapping a memory region into the system
> memory space, and have no users now. Sysbus devices should never map
> their own memory regions anyway; the correct
On Fri, Feb 15, 2013 at 10:32:31AM +0100, Peter Lieven wrote:
> historically the kernel queues packets two times. once
> at the device and second in qdisc. this is believed to cause
> interface stalls if one of these queues overruns.
>
> setting IFF_ONE_QUEUE is the default in kernels >= 3.8. the
On Fri, 15 Feb 2013 10:50:16 -0200
Eduardo Habkost wrote:
> Hi,
>
> This is an attempt to summarize my main question from the thread:
> Re: [Qemu-devel] [RFC v5] target-i386: Slim conversion to X86CPU
> subclasses + KVM subclasses
>
> My main unanswered question is about the "stability" expec
On Wed, Feb 13, 2013 at 02:22:08PM +0100, Kevin Wolf wrote:
> /**
> + * true if the request is sleeping in the COW delay and the coroutine may
> + * be reentered in order to cancel the timer.
> + */
> +bool sleeping;
Does reentering actually cancel the timer...or does it lead
Am 15.02.2013 14:38, schrieb Peter Maydell:
> On 15 February 2013 13:11, Andreas Färber wrote:
>> Am 15.02.2013 12:45, schrieb Peter Maydell:
>>> --- a/hw/musicpal.c
>>> +++ b/hw/musicpal.c
>>> @@ -1031,6 +1031,21 @@ static const TypeInfo mv88w8618_flashcfg_info = {
>>>
>>> #define MP_BOARD_REVIS
On 15 February 2013 13:11, Andreas Färber wrote:
> Am 15.02.2013 12:45, schrieb Peter Maydell:
>> --- a/hw/musicpal.c
>> +++ b/hw/musicpal.c
>> @@ -1031,6 +1031,21 @@ static const TypeInfo mv88w8618_flashcfg_info = {
>>
>> #define MP_BOARD_REVISION 0x31
>>
>> +typedef struct {
>
> Anonymous
On Fri, Feb 15, 2013 at 02:35:26PM +0100, Igor Mammedov wrote:
> On Fri, 15 Feb 2013 10:50:16 -0200
> Eduardo Habkost wrote:
>
> > Hi,
> >
> > This is an attempt to summarize my main question from the thread:
> > Re: [Qemu-devel] [RFC v5] target-i386: Slim conversion to X86CPU
> > subclasses +
On 15 February 2013 13:45, Andreas Färber wrote:
> Am 15.02.2013 14:38, schrieb Peter Maydell:
>> On 15 February 2013 13:11, Andreas Färber wrote:
>>> Am 15.02.2013 12:45, schrieb Peter Maydell:
--- a/hw/musicpal.c
+++ b/hw/musicpal.c
@@ -1031,6 +1031,21 @@ static const TypeInfo mv
On Fri, Feb 15, 2013 at 10:50:16AM +0100, Andreas Färber wrote:
> Am 15.02.2013 10:06, schrieb Stefan Hajnoczi:
> > In iPXE they use a clever compile-time debug macro:
> > https://git.ipxe.org/ipxe.git/blob/HEAD:/src/include/compiler.h#l204
> >
> > Basically you do DBG("hello world\n") and it gets
On Fri, Feb 15, 2013 at 02:36:37PM +0100, Stefan Hajnoczi wrote:
> On Wed, Feb 13, 2013 at 02:22:08PM +0100, Kevin Wolf wrote:
> > /**
> > + * true if the request is sleeping in the COW delay and the coroutine
> > may
> > + * be reentered in order to cancel the timer.
> > + */
> >
Factor out the handling of the SRS instruction rather than
duplicating it between the Thumb and ARM decoders. This in
passing fixes two bugs in the Thumb decoder's SRS handling
which didn't exist in the ARM decoder:
* (LP:1079080) storing CPSR rather than SPSR (fixed in the
ARM decoder in commi
M profile cores do not have the RFE or SRS instructions, so
correctly UNDEF these insn patterns on those cores.
Signed-off-by: Peter Maydell
---
target-arm/translate.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/target-arm/translate.c b/target-arm/translate.c
inde
This patchset fixes a couple of bugs in the handling of the SRS
instruction in the Thumb decoder, by refactoring the code so that
it is shared with the ARM decoder (where those bugs were fixed
or never present). The most significant one is LP:1079080, where
we were simply not storing the right thin
On 02/14/2013 04:43 PM, Stefan Berger wrote:
This patch adds support for TPM command line options.
The command line options supported here are
./qemu-... -tpmdev passthrough,path=,id=
-device tpm-tis,tpmdev=
and
./qemu-... -tpmdev help
where the latter works similar to -soundhw
Since we still need env for ppc-specific fields, obtain it via the new
env_ptr fields to avoid "cpu" name conflicts between CPUState and
PowerPCCPU for now.
This fixes a potential issue with env being NULL at the end of the loop
but cpu still being a valid pointer corresponding to a previous env.
Am 15.02.2013 um 14:32 schrieb Stefan Hajnoczi :
> On Fri, Feb 15, 2013 at 10:32:31AM +0100, Peter Lieven wrote:
>> historically the kernel queues packets two times. once
>> at the device and second in qdisc. this is believed to cause
>> interface stalls if one of these queues overruns.
>>
>> se
On 15.02.2013, at 15:25, Andreas Färber wrote:
> Since we still need env for ppc-specific fields, obtain it via the new
> env_ptr fields to avoid "cpu" name conflicts between CPUState and
> PowerPCCPU for now.
>
> This fixes a potential issue with env being NULL at the end of the loop
> but cpu
On 15/02/13 15:27, Peter Lieven wrote:
>
> Am 15.02.2013 um 14:32 schrieb Stefan Hajnoczi :
>
>> On Fri, Feb 15, 2013 at 10:32:31AM +0100, Peter Lieven wrote:
>>> historically the kernel queues packets two times. once
>>> at the device and second in qdisc. this is believed to cause
>>> interface
No functional change, just less usages of first_cpu and next_cpu fields.
Signed-off-by: Andreas Färber
---
cpus.c | 11 +++
1 Datei geändert, 3 Zeilen hinzugefügt(+), 8 Zeilen entfernt(-)
diff --git a/cpus.c b/cpus.c
index 41779eb..845e915 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1262,18
Eduardo Habkost writes:
> Hi,
>
> This is an attempt to summarize my main question from the thread:
> Re: [Qemu-devel] [RFC v5] target-i386: Slim conversion to X86CPU subclasses
> + KVM subclasses
>
> My main unanswered question is about the "stability" expectations of the
> introspectable cla
On 02/14/2013 04:43 PM, Stefan Berger wrote:
This patch adds support for cancelling an executing TPM command.
In Linux for example a user can cancel a command through the TPM's
sysfs 'cancel' entry using
echo "1" > /sysfs/class/misc/tpm0/device/cancel
This patch propagates the cancellation of
On 02/14/2013 04:43 PM, Stefan Berger wrote:
+/*
+ * Parse the TPM configuration options.
+ * To display all available TPM backends the user may use '-tpmdev ?'
This comment is out of date.
+ */
+int tpm_config_parse(QemuOptsList *opts_list, const char *optarg)
--
Regards,
Corey Bryant
Am 15.02.2013 15:29, schrieb Alexander Graf:
>
> On 15.02.2013, at 15:25, Andreas Färber wrote:
>
>> Since we still need env for ppc-specific fields, obtain it via the new
>> env_ptr fields to avoid "cpu" name conflicts between CPUState and
>> PowerPCCPU for now.
>>
>> This fixes a potential issu
this patch adds iscsi_truncate which effectively allows for online
resizing of iscsi volumes. for this to work you have to resize
the volume on your storage and then call block_resize command
in qemu which will issue a readcapacity16 to update the capacity.
v2:
- add a general bdrv_drain_all() b
On Fri, Feb 15, 2013 at 08:22:31AM -0600, Anthony Liguori wrote:
> Eduardo Habkost writes:
>
> > Hi,
> >
> > This is an attempt to summarize my main question from the thread:
> > Re: [Qemu-devel] [RFC v5] target-i386: Slim conversion to X86CPU
> > subclasses + KVM subclasses
> >
> > My main un
On Fri, Feb 15, 2013 at 02:06:56PM +0100, Igor Mammedov wrote:
> From: Andreas Färber
>
> In order to instantiate a CPU subtype we will need to know which type,
> so move the cpu_model splitting into cpu_x86_init().
>
> Parameters need to be set on the X86CPU instance, so move
> cpu_x86_parse_fe
Thanks -- I've submitted a patch which fixes this:
http://patchwork.ozlabs.org/patch/220748/
If you'd like to give me a name/email [format "Full Name
"] I can credit you in a Reported-by: tag in the
commit message...
--
You received this bug notification because you are a member of qemu-
devel-m
Il 15/02/2013 14:48, Peter Maydell ha scritto:
>>> >> If you prefer we could standardize on
>>> >> typedef struct {
>>> >> ParentClass parent;
>>> >> } FooClass;
>>> >>
>>> >> rather than typedef ParentClass FooClass;
>> > It may need rework either way. Because aliasing via typedef gives
Il 15/02/2013 12:45, Peter Maydell ha scritto:
> Don't map the pmem and dmem RAM memory regions in the milkymist-softusb
> device itself. Instead just expose them as sysbus mmio regions which
> the device creator can map appropriately. This allows us to drop the
> pmem_base and dmem_base properties
On 15 February 2013 15:21, Paolo Bonzini wrote:
> Il 15/02/2013 12:45, Peter Maydell ha scritto:
>> Don't map the pmem and dmem RAM memory regions in the milkymist-softusb
>> device itself. Instead just expose them as sysbus mmio regions which
>> the device creator can map appropriately. This allo
Am 15.02.2013 16:14, schrieb Paolo Bonzini:
> Il 15/02/2013 14:48, Peter Maydell ha scritto:
>> If you prefer we could standardize on
>> typedef struct {
>> ParentClass parent;
>> } FooClass;
>>
>> rather than typedef ParentClass FooClass;
It may need rework e
On 02/15/2013 12:24 PM, Andreas Färber wrote:
The expected answer would've been "take guest X and do Y to see Z", or
better to extend the existing qtest cases to prove something was broken
before and fixed afterwards and to avoid the same bug being reintroduced
later.
If we are talking about ad
The helper functions all access ppc-specific fields only so don't bother
to change arguments to PowerPCCPU and use env_ptr instead.
No functional change.
Signed-off-by: Andreas Färber
---
hw/spapr_hcall.c | 11 +++
1 Datei geändert, 3 Zeilen hinzugefügt(+), 8 Zeilen entfernt(-)
diff
Il 15/02/2013 16:35, Peter Maydell ha scritto:
>> > I think it's best to avoid storing long-lived host pointers. Ideally we
>> > should have no long-lived host pointers anytime the thread is quiescent
>> > (for CPUs that means kvm_cpu_exec or the end of qemu_tcg_wait_io_event;
>> > for I/O that me
No functional change, just a reduction of CPU loops.
The mon_cpu field is left untouched for now since changing that requires
a number of larger prerequisites, including cpu_synchronize_state() and
mon_get_cpu().
Signed-off-by: Andreas Färber
---
monitor.c | 13 +
1 Datei geändert
Il 15/02/2013 16:41, Antoine Mathys ha scritto:
> On 02/15/2013 12:24 PM, Andreas Färber wrote:
>> The expected answer would've been "take guest X and do Y to see Z", or
>> better to extend the existing qtest cases to prove something was broken
>> before and fixed afterwards and to avoid the same b
On 15 February 2013 16:06, Paolo Bonzini wrote:
> Il 15/02/2013 16:35, Peter Maydell ha scritto:
>>> > I think it's best to avoid storing long-lived host pointers. Ideally we
>>> > should have no long-lived host pointers anytime the thread is quiescent
>>> > (for CPUs that means kvm_cpu_exec or t
Il 15/02/2013 17:17, Peter Maydell ha scritto:
> But these memory regions belong to this device -- we own them and
> they won't go away until the device is destroyed [which is never,
> as it happens, for this device.] More generally, if it's valid
> for us to hold a MemoryRegion* and call memory_re
On 15 February 2013 15:14, Paolo Bonzini wrote:
> I like the empty-except-for-parentclass. OTOH, if you have no fields
> you will not use FOO_CLASS. You will only use PARENT_CLASS, and those
> uses will be fine even after you start having a FooClass.
OK, that makes sense I think, except there i
Am 15.02.2013 12:41, schrieb Peter Maydell:
> On 15 February 2013 11:24, Andreas Färber wrote:
>> Am 15.02.2013 03:49, schrieb Antoine Mathys:
>>> First, the ds1338 code was in a poor state and never handled the 12 hour
>>> clock correctly. My first patch failed to fully fix the problem so I had
>
On 15.02.2013, at 16:49, Andreas Färber wrote:
> The helper functions all access ppc-specific fields only so don't bother
> to change arguments to PowerPCCPU and use env_ptr instead.
>
> No functional change.
>
> Signed-off-by: Andreas Färber
Acked-by: Alexander Graf
Alex
> ---
> hw/spapr
Potentially env could be NULL whereas cpu would still be valid and
correspond to a previous env.
Wrapping this in qemu_get_cpu(), env is no longer needed, so simplify
code that existed before 55e5c2850293547203874098f7cec148ffd12dfa.
Signed-off-by: Andreas Färber
---
hw/ppce500_spin.c | 15 ++
On 15.02.2013, at 17:51, Andreas Färber wrote:
> Potentially env could be NULL whereas cpu would still be valid and
> correspond to a previous env.
>
> Wrapping this in qemu_get_cpu(), env is no longer needed, so simplify
> code that existed before 55e5c2850293547203874098f7cec148ffd12dfa.
>
>
On 15.02.2013, at 15:35, Andreas Färber wrote:
> Am 15.02.2013 15:29, schrieb Alexander Graf:
>>
>> On 15.02.2013, at 15:25, Andreas Färber wrote:
>>
>>> Since we still need env for ppc-specific fields, obtain it via the new
>>> env_ptr fields to avoid "cpu" name conflicts between CPUState and
Am 15.02.2013 17:54, schrieb Alexander Graf:
>
> On 15.02.2013, at 17:51, Andreas Färber wrote:
>
>> Potentially env could be NULL whereas cpu would still be valid and
>> correspond to a previous env.
>>
>> Wrapping this in qemu_get_cpu(), env is no longer needed, so simplify
>> code that existed
On 15.02.2013, at 17:58, Andreas Färber wrote:
> Am 15.02.2013 17:54, schrieb Alexander Graf:
>>
>> On 15.02.2013, at 17:51, Andreas Färber wrote:
>>
>>> Potentially env could be NULL whereas cpu would still be valid and
>>> correspond to a previous env.
>>>
>>> Wrapping this in qemu_get_cpu()
Am 14.02.2013 18:49, schrieb Andreas Färber:
> Am 01.02.2013 13:38, schrieb Andreas Färber:
>> Hello,
>>
>> This series moves more fields from CPU_COMMON / CPU*State to CPUState,
>> allowing access from target-independent code.
>>
>> The final patch in this series will help solve some issues (in pa
when debugging with qemu(user mode), qemu waits in infinite loop to read a
signal from gdb (when it waits on breakpoint for example).
I added sleeps to reduce the cpu usage from 100% to about ~0%.
qemu-busy-wait.patch
Description: Binary data
Public bug reported:
Something fishy is going on with qcow2 internal snapshot creation times.
I don't know if this is a regression because I haven't used internal
snapshots in the past.
QEMU 1.4-rc2:
$ qemu-img create -f qcow2 test.qcow2 -o size=50G,preallocation=metadata
$ time qemu-img snapshot
Am 15.02.2013 17:45, schrieb Alexander Graf:
>
> On 15.02.2013, at 15:35, Andreas Färber wrote:
>
>> Am 15.02.2013 15:29, schrieb Alexander Graf:
>>>
>>> On 15.02.2013, at 15:25, Andreas Färber wrote:
>>>
Since we still need env for ppc-specific fields, obtain it via the new
env_ptr fie
Am 15.02.2013 18:04, schrieb Alexander Graf:
>
> On 15.02.2013, at 17:58, Andreas Färber wrote:
>
>> Am 15.02.2013 17:54, schrieb Alexander Graf:
>>>
>>> On 15.02.2013, at 17:51, Andreas Färber wrote:
>>>
Potentially env could be NULL whereas cpu would still be valid and
correspond to a
1 - 100 of 191 matches
Mail list logo
