On 25 May 2015 at 22:55, Alexander Graf wrote:
> For linux-user we could just implement probe as
>
> foo = load_x_bytes(addr)
> store_x_bytes(addr, foo)
>
> or can we have write-only maps there?
The guest can mmap() things write-only, so yes.
-- PMM
On Tue, 26 May 2015 12:22:56 +1000
David Gibson wrote:
> The code for -machine pseries maintains a global sPAPREnvironment structure
> which keeps track of general state information about the guest platform.
> This predates the existence of the MachineState structure, but performs
> basically the
On 26 May 2015 at 00:58, Edgar E. Iglesias wrote:
> That's all OK I think. We've never used the save/restore/migration on
> CRIS so you won't be breaking anything for us...
I would actually recommend fixing it in the board/device models
just for debugging purposes. It's really handy to be able to
On Mon, 04/27 18:28, Paolo Bonzini wrote:
> This will be required soon by the memory core.
>
> Signed-off-by: Paolo Bonzini
> ---
> hw/display/cg3.c | 1 +
> hw/display/exynos4210_fimd.c | 20 +---
> hw/display/g364fb.c | 1 +
> hw/display/sm501.c
On 26 May 2015 at 06:49, Peter Crosthwaite wrote:
> From: Peter Crosthwaite
>
> The "arm" variant for this case already contains everything needed
> for aarch64. As aarch64 already uses arm as a base architecture, it
> will already have the CONFIG_ARM_DIS defined meaning no functional
> change. S
On Mon, 04/27 18:28, Paolo Bonzini wrote:
> DIRTY_MEMORY_MIGRATION is triggered by memory_global_dirty_log_start
> and memory_global_dirty_log_stop, so it cannot be used with
> memory_region_set_log.
>
> Specify this in the documentation and assert it.
>
> Signed-off-by: Paolo Bonzini
Reviewed-
On 2015/5/22 20:11, Cornelia Huck wrote:
> Move host_features from the individual transport proxies into
> the virtio device. Transports may continue to add feature bits
> during device plugging.
>
> This should it make easier to offer different sets of host features
> for virtio-1/transitional
On Mon, 04/27 18:28, Paolo Bonzini wrote:
> diff --git a/hw/display/tcx.c b/hw/display/tcx.c
> index 58faa96..2eb5aef 100644
> --- a/hw/display/tcx.c
> +++ b/hw/display/tcx.c
> @@ -353,6 +353,7 @@ static void tcx_update_display(void *opaque)
> return;
> }
>
> +memory_region_sync
hello everybody:
in linux kernel , when smp booting via spin tables , primary core use
sev instruction to wakeup the secondery cores .
but qemu don't support sev and wfe in TCG model . does somebody have
some idea about how to implemet wfe and sev
instruction on aarch64?
On Tue, 26 May 2015 14:58:02 +0800
Shannon Zhao wrote:
>
>
> On 2015/5/22 20:11, Cornelia Huck wrote:
> > Move host_features from the individual transport proxies into
> > the virtio device. Transports may continue to add feature bits
> > during device plugging.
> >
> > This should it make eas
On Mon, 04/27 18:28, Paolo Bonzini wrote:
> For now memory regions only track DIRTY_MEMORY_VGA individually, but
> this will change soon. To support this, split memory_region_is_logging
> in two functions: one that returns a given bit from dirty_log_mask,
> and one that returns the entire mask. m
On Mon, 04/27 18:28, Paolo Bonzini wrote:
> When the dirty log mask will also cover other bits than DIRTY_MEMORY_VGA,
> some listeners may be interested in the overall zero/non-zero value of
> the dirty log mask; others may be interested in the value of single bits.
>
> For this reason, always cal
Hi,
> 12:44:02.389552: EV_MSC MSC_SCAN 458887 <== Here, / was pressed
> 12:44:02.389552: EV_KEY KEY_RO (0x59) pressed
'RO'. Hmm, not very descriptive. Any idea what this could stand for?
> 12:44:04.253486: EV_MSC MSC_SCAN 458885 <== Here, . in the numpad was pressed
> 12:44:04.253486: EV_KEY
On Tue, May 26, 2015 at 12:29 AM, Pei XiaoYong wrote:
> hello everybody:
> in linux kernel , when smp booting via spin tables , primary core use
> sev instruction to wakeup the secondery cores .
> but qemu don't support sev and wfe in TCG model .
So it should still work as the semantic of wfe is
On Tue, 26 May 2015 12:22:57 +1000
David Gibson wrote:
> The ram_limit field was imported from sPAPREnvironment where it predates
> the machine's ram size being available generically from machine->ram_size.
>
> Worse, the existing code was inconsistent about where it got the ram size
> from. So
On Tue, May 26, 2015 at 12:18 AM, Peter Maydell
wrote:
> On 26 May 2015 at 06:49, Peter Crosthwaite wrote:
>> From: Peter Crosthwaite
>>
>> The "arm" variant for this case already contains everything needed
>> for aarch64. As aarch64 already uses arm as a base architecture, it
>> will already ha
On Mon, 04/27 18:28, Paolo Bonzini wrote:
> framebuffer.c expects DIRTY_MEMORY_VGA logging to be always on, but that
> will not be the case soon. Because framebuffer.c computes the memory
> region on the fly for every update (with memory_region_find), it cannot
> enable/disable logging by itself.
On Mon, 04/27 18:28, Paolo Bonzini wrote:
> dpy_gfx_update_dirty expects DIRTY_MEMORY_VGA logging to be always on,
> but that will not be the case soon. Because it computes the memory
> region on the fly for every update (with memory_region_find), it cannot
> enable/disable logging by itself.
>
>
On Tue, 26 May 2015 12:22:58 +1000
David Gibson wrote:
> The sPAPRMachineState structure includes an entry_point field containing
> the initial PC value for starting the machine, even though this always has
> the value 0x100.
>
> I think this is a hangover from very early versions which bypassed
On Mon, 04/27 18:28, Paolo Bonzini wrote:
> DIRTY_MEMORY_CODE is only needed for TCG. By adding it directly to
> mr->dirty_log_mask, we avoid testing for TCG everywhere a region is
> checked for the enabled/disabled state of dirty logging.
>
> Signed-off-by: Paolo Bonzini
Reviewed-by: Fam Zheng
On 26/05/2015 08:00, Peter Crosthwaite wrote:
> Eduardo flagged a conflict with on-list work. Do you want me to handle it?
I don't know, but I'll dequeue these patches.
Paolo
On 26/05/2015 08:10, Andreas Färber wrote:
> Am 25.05.2015 um 15:08 schrieb Paolo Bonzini:
>> On 25/05/2015 08:22, Peter Crosthwaite wrote:
>>> Hi Andreas, Richard and all,
>>>
>>> I'm moving towards the goal of having no core code usages of ENV_GET_CPU.
>>> This has two advantages:
>>>
>>> 1: It
On Mon, 04/27 18:28, Paolo Bonzini wrote:
> It is okay if memory is not mapped into the guest but has dirty logging
> enabled. When this happens, KVM will not do anything and only accesses
> from the host will be logged.
>
> Signed-off-by: Paolo Bonzini
Could you explain where this change is ne
On 26/05/2015 08:38, Peter Crosthwaite wrote:
> Rather than an explicit inclusion of cpu.h. This maked it more
> consistent with other core code files, which either just rely on
> qemu-common.h inclusion or preceed cpu.h with qemu-common.h anyway.
I'd rather keep the cpu.h inclusion. It would b
John Snow writes:
> On 05/22/2015 04:52 AM, Markus Armbruster wrote:
>> Eric Blake writes:
>>
>>> On 05/12/2015 01:53 PM, John Snow wrote:
Bitmaps can be in a handful of different states with potentially
more to come as we tool around with migration and persistence patches.
On 26/05/2015 09:13, Fam Zheng wrote:
>> > hw/display/cg3.c | 1 +
>> > hw/display/exynos4210_fimd.c | 20 +---
>> > hw/display/g364fb.c | 1 +
>> > hw/display/sm501.c | 1 +
>> > hw/display/tcx.c | 1 +
>> > 5 files changed, 17 inse
On 26/05/2015 09:36, Fam Zheng wrote:
> On Mon, 04/27 18:28, Paolo Bonzini wrote:
>> diff --git a/hw/display/tcx.c b/hw/display/tcx.c
>> index 58faa96..2eb5aef 100644
>> --- a/hw/display/tcx.c
>> +++ b/hw/display/tcx.c
>> @@ -353,6 +353,7 @@ static void tcx_update_display(void *opaque)
>>
On 26/05/2015 10:10, Fam Zheng wrote:
> > It is okay if memory is not mapped into the guest but has dirty logging
> > enabled. When this happens, KVM will not do anything and only accesses
> > from the host will be logged.
> >
> > Signed-off-by: Paolo Bonzini
>
> Could you explain where this
On Tue, 26 May 2015 12:22:59 +1000
David Gibson wrote:
> Currently although we have an sPAPRMachineState descended from MachineState
> we don't have an sPAPRMAchineClass descended from MachineClass. So far it
> hasn't been needed, but several upcoming features are going to want it,
> so this pat
Am 26.05.2015 um 10:05 schrieb Paolo Bonzini:
> On 26/05/2015 08:10, Andreas Färber wrote:
>> Am 25.05.2015 um 15:08 schrieb Paolo Bonzini:
>>> On 25/05/2015 08:22, Peter Crosthwaite wrote:
Hi Andreas, Richard and all,
I'm moving towards the goal of having no core code usages of ENV_
On Tue, 05/26 10:16, Paolo Bonzini wrote:
>
>
> On 26/05/2015 10:10, Fam Zheng wrote:
> > > It is okay if memory is not mapped into the guest but has dirty logging
> > > enabled. When this happens, KVM will not do anything and only accesses
> > > from the host will be logged.
> > >
> > > Signed
On 26 May 2015 at 09:01, Peter Crosthwaite wrote:
> On Tue, May 26, 2015 at 12:18 AM, Peter Maydell
> wrote:
>> On 26 May 2015 at 06:49, Peter Crosthwaite
>> wrote:
>>> From: Peter Crosthwaite
>>>
>>> The "arm" variant for this case already contains everything needed
>>> for aarch64. As aarch6
On 26/05/2015 10:20, Andreas Färber wrote:
> Am 26.05.2015 um 10:05 schrieb Paolo Bonzini:
>> On 26/05/2015 08:10, Andreas Färber wrote:
>>> Am 25.05.2015 um 15:08 schrieb Paolo Bonzini:
On 25/05/2015 08:22, Peter Crosthwaite wrote:
> Hi Andreas, Richard and all,
>
> I'm moving t
On 26.05.15 08:02, Aurelien Jarno wrote:
> On 2015-05-25 23:47, Alexander Graf wrote:
>>
>>
>> On 25.05.15 23:13, Aurelien Jarno wrote:
>>> On 2015-05-25 23:04, Alexander Graf wrote:
On 25.05.15 23:02, Aurelien Jarno wrote:
> On 2015-05-25 22:39, Alexander Graf wrote:
>>
>>
> -Original Message-
> From: Pavel Fedin [mailto:p.fe...@samsung.com]
> Sent: Monday, 25 May, 2015 6:27 PM
> To: 'Eric Auger'; qemu-devel@nongnu.org; shlomopongr...@gmail.com;
> Shlomo Pongratz
> Subject: RE: [Qemu-devel] [PATCH RFC V2 2/4] Implment GIC-500
>
> Hi!
>
> > > +static const
Am 26.05.2015 um 10:25 schrieb Paolo Bonzini:
>
>
> On 26/05/2015 10:20, Andreas Färber wrote:
>> Am 26.05.2015 um 10:05 schrieb Paolo Bonzini:
>>> On 26/05/2015 08:10, Andreas Färber wrote:
Am 25.05.2015 um 15:08 schrieb Paolo Bonzini:
> On 25/05/2015 08:22, Peter Crosthwaite wrote:
>>>
On 26.05.15 10:31, Andreas Färber wrote:
> Am 26.05.2015 um 10:25 schrieb Paolo Bonzini:
>>
>>
>> On 26/05/2015 10:20, Andreas Färber wrote:
>>> Am 26.05.2015 um 10:05 schrieb Paolo Bonzini:
On 26/05/2015 08:10, Andreas Färber wrote:
> Am 25.05.2015 um 15:08 schrieb Paolo Bonzini:
>>
On 26/05/2015 10:31, Andreas Färber wrote:
>>> It's not about which tree it goes through, it's about you not
>>> asking first - which I reminded you of just days ago, so this appears
>>> deliberate.
>>
>> It certainly is.
>
> Then you can fix up Daniel's patch yourself and I am stepping down as
On Mon, 04/27 18:28, Paolo Bonzini wrote:
> The separate handling of DIRTY_MEMORY_MIGRATION, which does not
> call log_start/log_stop callbacks when it changes in a region's
> dirty logging mask, has caused several bugs.
>
> One recent example is commit 4cc856f (kvm-all: Sync dirty-bitmap from
> k
On Fri, May 22, 2015 at 10:53:54AM +0800, Yong Wang wrote:
> On Thu, May 21, 2015 at 03:51:43PM +0200, Paolo Bonzini wrote:
> > On the QEMU side, there is no support yet for persistent memory and the
> > NFIT tables from ACPI 6.0. Once that (and ACPI support) is added, qboot
> > will automatically
On 05/26/2015 04:46 AM, Shannon Zhao wrote:
From: Shannon Zhao
valgrind complains about:
==16447== 16 bytes in 2 blocks are definitely lost in loss record 1,304 of 3,310
==16447==at 0x4C2845D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16447==by 0x2E4FD7: mallo
On Mon, 04/27 18:28, Paolo Bonzini wrote:
> One recent example is commit 4cc856f (kvm-all: Sync dirty-bitmap from
> kvm before kvm destroy the corresponding dirty_bitmap, 2015-04-02).
> Another performance problem is that KVM keeps tracking dirty pages
> after a failed live migration, which causes
On 26 May 2015 at 09:36, Paolo Bonzini wrote:
> On 26/05/2015 10:31, Andreas Färber wrote:
It's not about which tree it goes through, it's about you not
asking first - which I reminded you of just days ago, so this appears
deliberate.
>>>
>>> It certainly is.
>>
>> Then you can fix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 26/05/2015 04:46, David Gibson wrote:
> On Tue, May 26, 2015 at 01:05:56AM +1000, Alexey Kardashevskiy
> wrote:
>> Hi Paolo,
>>
>> I have had a conversation with Mike and it turns out I am not
>> allowed to create/remove memory regions dynami
Eric Blake writes:
> On 05/22/2015 05:36 AM, Markus Armbruster wrote:
>> Signed-off-by: Markus Armbruster
>> ---
>
> Commit message is sparse; I would have mentioned [1] and [2].
>
>> monitor.c | 40 +++-
>> 1 file changed, 11 insertions(+), 29 deletions(-)
>
On 05/26/2015 04:46 AM, Shannon Zhao wrote:
From: Shannon Zhao
valgrind complains about:
==16447== 8 bytes in 1 blocks are definitely lost in loss record 552 of 3,310
==16447==at 0x4C2845D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16447==by 0x2E4FD7: malloc_a
Eric Blake writes:
> On 05/22/2015 05:36 AM, Markus Armbruster wrote:
>> The asynchronous monitor command interface goes back to commit 940cc30
>> (Jan 2010). Added a third case to command execution. The hope back
>> then according to the commit message was that all commands get
>> converted to
On 26.05.15 10:58, Paolo Bonzini wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
>
> On 26/05/2015 04:46, David Gibson wrote:
>> On Tue, May 26, 2015 at 01:05:56AM +1000, Alexey Kardashevskiy
>> wrote:
>>> Hi Paolo,
>>>
>>> I have had a conversation with Mike and it turns out I
On 2015-05-26 10:29, Alexander Graf wrote:
>
>
> On 26.05.15 08:02, Aurelien Jarno wrote:
> > On 2015-05-25 23:47, Alexander Graf wrote:
> >>
> >>
> >> On 25.05.15 23:13, Aurelien Jarno wrote:
> >>> On 2015-05-25 23:04, Alexander Graf wrote:
>
>
> On 25.05.15 23:02, Aurelien Jarno
On 26/05/2015 10:40, Fam Zheng wrote:
>> > void memory_global_dirty_log_stop(void)
>> > {
>> > +/* Refresh DIRTY_LOG_MIGRATION bit. */
>> > +memory_region_transaction_begin();
>> > +memory_region_update_pending = true;
>> > +memory_region_transaction_commit();
>> > +
>> >
On 26/05/2015 10:40, Fam Zheng wrote:
> > @@ -1329,7 +1329,11 @@ bool memory_region_is_skip_dump(MemoryRegion *mr)
> >
> > uint8_t memory_region_get_dirty_log_mask(MemoryRegion *mr)
> > {
> > -return mr->dirty_log_mask;
> > +uint8_t mask = mr->dirty_log_mask;
> > +if (global_dirty
Hello!
> The value is taken from the gic-500 document in the re-distributer's table
> (3-7).
> I don't know where the value 0x91 comes from as GICD_PIDR0 is 0x92,
> GICR_PIDR0 is 0x93
and
> GITS_PIDR0 is 0x94.
> In the GICv3 document section 5.4.21 it is also been written:
> 0xFFE0 GICR_PIDR0
Eric Blake writes:
> On 05/22/2015 05:36 AM, Markus Armbruster wrote:
>> Signed-off-by: Markus Armbruster
>> ---
>> hmp-commands.hx | 3 +--
>> hmp.c| 17 +
>> hmp.h| 1 +
>> monitor.c| 42 ++
>> qapi-sch
On 26/05/2015 11:01, Alexander Graf wrote:
>>> So, the sentences after that one note an exception for alias and
>>> >> container regions. I think iommu regions should behave similarly
>>> >> - in a sense they're just a procedurally generated collection of
>>> >> alias regions.
>> >
>> > The d
On Tue, May 26, 2015 at 02:52:48PM +0800, Fam Zheng wrote:
> On Tue, 05/19 15:48, Stefan Hajnoczi wrote:
> > On Tue, May 19, 2015 at 10:51:00AM +, Fam Zheng wrote:
> > > This callback is called by main loop before polling s->fd, if it returns
> > > false, the fd will not be polled in this itera
On Mon, May 25, 2015 at 11:51:23AM +0800, Fam Zheng wrote:
> On Tue, 05/19 15:54, Stefan Hajnoczi wrote:
> > On Tue, May 19, 2015 at 10:51:01AM +, Fam Zheng wrote:
> > > This callback is called by main loop before polling s->fd, if it returns
> > > false, the fd will not be polled in this itera
On Tue, 05/26 11:07, Paolo Bonzini wrote:
>
>
> On 26/05/2015 10:40, Fam Zheng wrote:
> > > @@ -1329,7 +1329,11 @@ bool memory_region_is_skip_dump(MemoryRegion *mr)
> > >
> > > uint8_t memory_region_get_dirty_log_mask(MemoryRegion *mr)
> > > {
> > > -return mr->dirty_log_mask;
> > > +
When consecutive memory locations are on page boundary a page fault
might occur when using the LOAD MULTIPLE instruction. In that case real
hardware doesn't load any register.
This is an important detail in case the base register is in the list
of registers to be loaded. If a page fault occurs thi
On 26/05/2015 05:36, Fam Zheng wrote:
> Like bdrv_is_allocated_above, this function follows the backing chain until
> seeing
> BDRV_BLOCK_ALLOCATED. Base is not included.
>
> Reimplement bdrv_is_allocated on top.
>
> Signed-off-by: Fam Zheng
> ---
> block/io.c| 53
> +++
On Wed, May 20, 2015 at 12:05:55PM +0200, Kevin Wolf wrote:
> Suggested-by: Markus Armbruster
> Signed-off-by: Kevin Wolf
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Stefan Hajnoczi
pgpEsHc_fpoXb.pgp
Description: PGP signature
Eric Blake writes:
> On 05/22/2015 05:36 AM, Markus Armbruster wrote:
>> All QMP commands use the "new" handler interface (mhandler.cmd_new).
>> Most HMP commands still use the traditional interface (mhandler.cmd),
>> but a few use the "new" one. Complicates handle_user_command() for no
>> gain,
On 26/05/2015 11:22, Fam Zheng wrote:
> > > @@ -1329,7 +1329,11 @@ bool memory_region_is_skip_dump(MemoryRegion
> > > *mr)
> > >
> > > uint8_t memory_region_get_dirty_log_mask(MemoryRegion *mr)
> > > {
> > > -return mr->dirty_log_mask;
> > > +uint8_
Eric Blake writes:
> On 05/22/2015 05:36 AM, Markus Armbruster wrote:
>> Signed-off-by: Markus Armbruster
>> ---
>> monitor.c | 19 ++-
>> 1 file changed, 10 insertions(+), 9 deletions(-)
>>
>
>> @@ -4948,27 +4948,27 @@ static QDict *qmp_check_input_obj(QObject *input_obj)
>
>>
Eric Blake writes:
> On 05/22/2015 05:36 AM, Markus Armbruster wrote:
>> The previous commits narrowed use of QError to handle_qmp_command()
>> and its helpers monitor_protocol_emitter(), build_qmp_error_dict().
>> Narrow it further to just the command handler call: instead of
>> converting Error
Eric Blake writes:
> On 05/22/2015 05:36 AM, Markus Armbruster wrote:
>> While there, rename its type as well, from MonitorControl to
>> MonitorQMP.
>>
>> Signed-off-by: Markus Armbruster
>> ---
>> monitor.c | 35 ---
>> 1 file changed, 16 insertions(+), 19 dele
On Tue, 05/26 11:26, Paolo Bonzini wrote:
>
>
> On 26/05/2015 11:22, Fam Zheng wrote:
> > > > @@ -1329,7 +1329,11 @@ bool
> > > > memory_region_is_skip_dump(MemoryRegion *mr)
> > > >
> > > > uint8_t memory_region_get_dirty_log_mask(MemoryRegion *mr)
> > > > {
>
Eric Blake writes:
> On 05/22/2015 05:36 AM, Markus Armbruster wrote:
>> Signed-off-by: Markus Armbruster
>> ---
>> monitor.c | 23 ---
>> 1 file changed, 12 insertions(+), 11 deletions(-)
>>
>
> Might be worth mentioning in the commit message that...
>
>>
>> -static inli
Eric Blake writes:
> On 05/22/2015 05:36 AM, Markus Armbruster wrote:
>> Signed-off-by: Markus Armbruster
>> ---
>> include/monitor/monitor.h | 2 +-
>> monitor.c | 6 --
>> stubs/mon-is-qmp.c| 2 +-
>> 3 files changed, 6 insertions(+), 4 deletions(-)
>>
>
>> +++ b/
* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:
> On 2015/4/15 1:04, Dr. David Alan Gilbert (git) wrote:
> >From: "Dr. David Alan Gilbert"
> >
> >userfaultfd is a Linux syscall that gives an fd that receives a stream
> >of notifications of accesses to pages registered with it and allows
>
On Tue, 05/26 11:22, Paolo Bonzini wrote:
>
>
> On 26/05/2015 05:36, Fam Zheng wrote:
> > Like bdrv_is_allocated_above, this function follows the backing chain until
> > seeing
> > BDRV_BLOCK_ALLOCATED. Base is not included.
> >
> > Reimplement bdrv_is_allocated on top.
> >
> > Signed-off-by:
On Thu, May 21, 2015 at 05:44:48PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Currently QEMU dynamically generates mac address for the NIC which
> doesn't specify the mac address. But when we hotplug a NIC without
> specifying mac address, the mac address will increase for the same NIC
>
On Fri, May 22, 2015 at 12:01:41PM -0400, John Snow wrote:
> RHEL6 doesn't have Python 2.7, so replace this call with
> assertNotEqual(x, None) which will work just as well.
>
> Reported-by: Kevin Wolf
> Signed-off-by: John Snow
> ---
> tests/qemu-iotests/124 | 2 +-
> 1 file changed, 1 inserti
On 05/26/2015 06:58 PM, Paolo Bonzini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 26/05/2015 04:46, David Gibson wrote:
On Tue, May 26, 2015 at 01:05:56AM +1000, Alexey Kardashevskiy
wrote:
Hi Paolo,
I have had a conversation with Mike and it turns out I am not
allowed to crea
On 26/05/2015 12:15, Alexey Kardashevskiy wrote:
> There was a "[RFC PATCH 00/15] spapr: add support for PHB hotplug"
> patchset from Mike, this patch added "unrealize" for spapr_phb:
>
> [RFC PATCH 05/15] spapr_pci: add PHB unrealize
>
> I believe I am dealing with the fixed version of this pa
On Sun, May 24, 2015 at 07:54:19AM -, Коренберг Марк wrote:
> Sorry, I did not know tha qed is just experimental format. I thought
> that qed is successor of qcow2. Can you add some links that qcow is not
> worse than qed ? I did not make any benchmark, just read some articles
Hi,
QED's write
On 05/26/2015 11:05 AM, Aurelien Jarno wrote:
On 2015-05-26 10:29, Alexander Graf wrote:
On 26.05.15 08:02, Aurelien Jarno wrote:
On 2015-05-25 23:47, Alexander Graf wrote:
On 25.05.15 23:13, Aurelien Jarno wrote:
On 2015-05-25 23:04, Alexander Graf wrote:
On 25.05.15 23:02, Aurelien Jarn
On Fri, 22 May 2015 15:56:13 +0200
Gerd Hoffmann wrote:
> Hi,
>
> Where we are in terms of virtio 1.0 support in qemu?
>
> There hasn't been much activity in mst's virtio-1.0 branch recently, at
> least not in the public version of it. And it doesn't rebase easily to
> latest master any more
On 22 May 2015 at 16:26, Kevin Wolf wrote:
> The following changes since commit 8b6db32a4ec47d1171ccfa21d557096b99f4eef0:
>
> Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request'
> into staging (2015-05-22 13:25:40 +0100)
>
> are available in the git repository at:
>
>
> gi
On Mon, 04/27 18:28, Paolo Bonzini wrote:
> The memory API can now return the exact set of bitmaps that have to
> be tracked. Use it instead of the in_migration variable.
>
> In the next patches, we will also use it to set only DIRTY_MEMORY_VGA
> or DIRTY_MEMORY_MIGRATION if necessary. This can
On Mon, 04/27 18:28, Paolo Bonzini wrote:
> Remove them from the sundry exec-all.h header, since they are only used by
> the TCG runtime in exec.c and user-exec.c.
>
> Signed-off-by: Paolo Bonzini
Reviewed-by: Fam Zheng
On Mon, 04/27 18:28, Paolo Bonzini wrote:
> The is_cpu_write_access argument is always 0, remove it.
>
> Signed-off-by: Paolo Bonzini
Reviewed-by: Fam Zheng
On Mon, 04/27 18:28, Paolo Bonzini wrote:
> These days modification of the TLB is done in notdirty_mem_write,
> so the virtual address and env pointer as unnecessary.
>
> The new name of the function, tlb_unprotect_code, is consistent with
> tlb_protect_code.
>
> Signed-off-by: Paolo Bonzini
Re
On 26/05/2015 12:42, Fam Zheng wrote:
> On Mon, 04/27 18:28, Paolo Bonzini wrote:
>> The memory API can now return the exact set of bitmaps that have to
>> be tracked. Use it instead of the in_migration variable.
>>
>> In the next patches, we will also use it to set only DIRTY_MEMORY_VGA
>> or D
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 26/05/2015 12:18, Stefan Hajnoczi wrote:
> On Sun, May 24, 2015 at 07:54:19AM -, Коренберг Марк wrote:
>> Sorry, I did not know tha qed is just experimental format. I
>> thought that qed is successor of qcow2. Can you add some links
>> that
HI,
Does anyone know why these *.dsl files exist in qemu project? Since
these files are used to define some hardware resource and operation
methods tables, i thought that they should be in the bios related
project, right?
$ls -l hw/i386/*.dsl
-rw-rw-r-- 1 admin admin 3872 May 26 10:43 hw/i386/ac
On Mon, 04/27 18:28, Paolo Bonzini wrote:
> This cuts in half the cost of bitmap operations (which will become more
> expensive when made atomic) during migration on non-VRAM regions.
>
> Signed-off-by: Paolo Bonzini
> ---
> exec.c | 20 +++-
> include/exec/ram_a
The goal of stateless, and thus this change, is to separate OS configuration
from system administrator configuration. With this change we will read the
default configuration data from /usr/share/defaults/qemu, in the absence of
an overriding site administrator configuration in /etc/qemu.
A key adv
On Tue, 05/26 12:58, Paolo Bonzini wrote:
>
>
> On 26/05/2015 12:42, Fam Zheng wrote:
> > On Mon, 04/27 18:28, Paolo Bonzini wrote:
> >> The memory API can now return the exact set of bitmaps that have to
> >> be tracked. Use it instead of the in_migration variable.
> >>
> >> In the next patches
On 26/05/2015 13:06, Zhi Yong Wu wrote:
> HI,
>
> Does anyone know why these *.dsl files exist in qemu project? Since
> these files are used to define some hardware resource and operation
> methods tables, i thought that they should be in the bios related
> project, right?
>
> $ls -l hw/i386/*.
On 22/05/15 22:58, Eric Blake wrote:
On 05/22/2015 09:42 AM, Ikey Doherty wrote:
meta-comment:
1.9.1
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 8
On 26/05/2015 10:02, Fam Zheng wrote:
> On Mon, 04/27 18:28, Paolo Bonzini wrote:
>> framebuffer.c expects DIRTY_MEMORY_VGA logging to be always on, but that
>> will not be the case soon. Because framebuffer.c computes the memory
>> region on the fly for every update (with memory_region_find), i
On Tue, May 26, 2015 at 7:13 PM, Paolo Bonzini wrote:
>
>
> On 26/05/2015 13:06, Zhi Yong Wu wrote:
>> HI,
>>
>> Does anyone know why these *.dsl files exist in qemu project? Since
>> these files are used to define some hardware resource and operation
>> methods tables, i thought that they should
On 26/05/2015 13:11, Ikey Doherty wrote:
> The goal of stateless, and thus this change, is to separate OS configuration
> from system administrator configuration. With this change we will read the
> default configuration data from /usr/share/defaults/qemu, in the absence of
> an overriding site a
Peter, Mark, Aurelien, can you review and ack this patch?
Thanks,
Paolo
On 27/04/2015 18:28, Paolo Bonzini wrote:
> This will be required soon by the memory core.
>
> Signed-off-by: Paolo Bonzini
> ---
> hw/display/cg3.c | 1 +
> hw/display/exynos4210_fimd.c | 20 +---
On Mon, 04/27 18:28, Paolo Bonzini wrote:
> While it is obvious that cpu_physical_memory_get_dirty returns true even if
> a single page is dirty, the same is not true for
> cpu_physical_memory_get_clean;
> one would expect that it returns true only if all the pages are clean, but
> it actually loo
On 26/05/2015 13:08, Fam Zheng wrote:
>> > +if (likely(mask & (1 << DIRTY_MEMORY_MIGRATION))) {
>> > +bitmap_set(ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION], page,
>> > end - page);
> Wrap the line? Other than that:
>
> Reviewed-by: Fam Zheng
Yes, the line gets shorter at the en
On Mon, 04/27 18:28, Paolo Bonzini wrote:
> Most of the time, not all bitmaps have to be marked as dirty;
> do not do anything if the interesting ones are already dirty.
> Previously, any clean bitmap would have cause all the bitmaps to be
> marked dirty.
>
> In fact, unless running TCG most of th
On Mon, 04/27 18:28, Paolo Bonzini wrote:
> cpu_physical_memory_set_dirty_lebitmap unconditionally syncs the
> DIRTY_MEMORY_CODE bitmap. This however is unused unless TCG is
> enabled.
>
> Signed-off-by: Paolo Bonzini
Reviewed-by: Fam Zheng
On 26/05/2015 09:46, Fam Zheng wrote:
>> > *
>> > - * Returns %true if the memory region is logging writes
>> > + * Returns %true if the memory region is logging writes for the given
>> > client
>> > + * a bitmap of clients for which the memory region is logging writes.
> I can't parse this se
Am 22.05.2015 um 18:01 hat John Snow geschrieben:
> RHEL6 doesn't have Python 2.7, so replace this call with
> assertNotEqual(x, None) which will work just as well.
>
> Reported-by: Kevin Wolf
> Signed-off-by: John Snow
Thanks, applied to the block branch.
Kevin
1 - 100 of 370 matches
Mail list logo
