On Sat, Feb 20, 2016 at 10:03 AM, Jean-Christophe DUBOIS
wrote:
> Le 20/02/2016 16:30, Peter Crosthwaite a écrit :
>>
>> On Sat, Feb 20, 2016 at 2:55 AM, Jean-Christophe DUBOIS
>> wrote:
>>>
>>> Just to compare I tried to run Linux on QEMU emulating highbank.
>>>
>>> For now I am unable to start
On Fri, Feb 19, 2016 at 10:02:16AM +0100, Didier Pallard wrote:
> Hi victor,
>
> I'm sorry, i didn't get time to work on this patch.
> Thanks for your work.
>
> didier
Could you please confirm that the patch works for you?
>
> On 02/18/2016 03:12 PM, Victor Kaplansky wrote:
> >Since guest_mask
Le 20/02/2016 16:30, Peter Crosthwaite a écrit :
On Sat, Feb 20, 2016 at 2:55 AM, Jean-Christophe DUBOIS
wrote:
Just to compare I tried to run Linux on QEMU emulating highbank.
For now I am unable to start in SMP mode. Only one core is activated.
This is probably due to the fact that the PSC
Signed-off-by: Max Reitz
---
block/null.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/block/null.c b/block/null.c
index ad883d9..0a8ff7b 100644
--- a/block/null.c
+++ b/block/null.c
@@ -186,6 +186,19 @@ static int null_reopen_prepare(BDRVReopenState
*reopen_state,
Using -S 0 is supposed to allocate everything in the output image; or at
least it is supposed to always explicitly write zeros even if the area
in question is known to only contain zeros. That doesn't always work
right now, so this series fixes it (patch 1, to be specific).
I only noticed after I
Currently, we do not define exactly what is returned when read, but
having a reliable source of zeros is always nice.
Signed-off-by: Max Reitz
---
block/null.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/block/null.c b/block/null.c
index d90165d..ad883d9 100644
--- a/block/null.c
+++ b
Passing -S 0 to qemu-img convert should result in all source data being
copied to the output, even if that source data is known to be 0. The
output image should therefore have exactly the same size on disk as an
image which we explicitly filled with data.
Signed-off-by: Max Reitz
---
tests/qemu-
When passing -S 0 to qemu-img convert, the target image is supposed to
be fully allocated. Right now, this is not the case if the source image
contains areas which bdrv_get_block_status() reports as being zero.
This patch introduces a new ImgConvertBlockStatus named BLK_ZERO_DATA
which is set by c
On Sat, Feb 20, 2016 at 2:55 AM, Jean-Christophe DUBOIS
wrote:
> Just to compare I tried to run Linux on QEMU emulating highbank.
>
> For now I am unable to start in SMP mode. Only one core is activated.
>
This is probably due to the fact that the PSCI command encodings for
Highbank expected by t
On 18.02.2016 21:37, Sascha Silbe wrote:
> Yet another IDE-using test crept in (commit 16dee418). Fix it by
> disabling the implicit drive.
>
> v1->v2:
> - don't use any drive at all instead of replacing IDE with virtio-scsi
> - split off virtio alias patch into separate series (no longer needed
>
On 18.02.2016 21:37, Sascha Silbe wrote:
> Describe in a little more detail what the test is supposed to achieve.
>
> Signed-off-by: Sascha Silbe
> ---
> Max, does this reflect your intentions well enough? I took the liberty
> of re-using some of your review comments to extend the description.
Y
On 19.02.2016 14:01, Sascha Silbe wrote:
> The relative ordering of "device_del" return value and the
> "DEVICE_DELETED" QMP event depends on the architecture being
> tested. On x86 unplugging virtio disks is asynchronous
> (=qdev_unplug()= → =hotplug_handler_unplug_request()=) while on s390x
> it
On 19.02.2016 12:24, Alberto Garcia wrote:
> On Fri 19 Feb 2016 09:26:53 AM CET, Wen Congyang wrote:
>
If quorum has two children(A, B). A do flush sucessfully, but B
flush failed. We MUST choice A as winner rather than just pick
anyone of them. Otherwise the filesystem of guest w
On 17.02.2016 16:51, Kevin Wolf wrote:
> Am 16.02.2016 um 19:08 hat Max Reitz geschrieben:
>> Move bdrv_commit_all() and bdrv_flush_all() to the BlockBackend level.
>>
>> Signed-off-by: Max Reitz
>> ---
>> block.c | 20
>> block/block-backend.c
Hi Mark, it is very good to hear that it isn't only with me.
Let me know if you need a help to test and/or collect any information to
help you to discover/fix this problem.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs
On 20.02.2016 14:34, Max Reitz wrote:
> On 17.02.2016 17:20, Kevin Wolf wrote:
>> Am 17.02.2016 um 16:41 hat Max Reitz geschrieben:
>>> On 17.02.2016 11:53, Kevin Wolf wrote:
Am 16.02.2016 um 19:08 hat Max Reitz geschrieben:
> The monitor does hold references to some BlockBackends so it sh
On 17.02.2016 17:20, Kevin Wolf wrote:
> Am 17.02.2016 um 16:41 hat Max Reitz geschrieben:
>> On 17.02.2016 11:53, Kevin Wolf wrote:
>>> Am 16.02.2016 um 19:08 hat Max Reitz geschrieben:
The monitor does hold references to some BlockBackends so it should have
>>>
>>> s/does hold/holds/?
>>
>>
On 2016/2/20 2:20, Gabriel L. Somlo wrote:
Add a fw_cfg device node to the ACPI DSDT. This is mostly
informational, as the authoritative fw_cfg MMIO region(s)
are listed in the Device Tree. However, since we are building
ACPI tables, we might as well be thorough while at it...
Signed-off-by: G
I've been looking at this as I have time, and IMO it's a qemu bug.
Fortunately I have a easy local reproducer here, and from what I can see
in this one particular case it seems the QEMU doesn't honour the annul
bit in the branch (or apparently corrupts it according to the guest?!).
So yes, it's a k
On 19 February 2016 at 21:58, Laszlo Ersek wrote:
> On 02/19/16 22:41, Ard Biesheuvel wrote:
>> On 19 February 2016 at 22:03, Laszlo Ersek wrote:
>>> Ard, any opinion on this?
>>>
>>
>> I agree with Peter. Note that this is strictly about emulation, under
>> KVM we always run at EL1 or below and
On 19 February 2016 at 19:38, Alistair Francis wrote:
> On Fri, Feb 19, 2016 at 6:39 AM, Peter Maydell
> wrote:
>> +/* Check for traps to performance monitor registers, which are controlled
>> + * by MDCR_EL2.TPM for EL2 and MDCR_EL3.TPM for EL3.
>> + */
>> +static CPAccessResult access_tpm(CPUA
Just to compare I tried to run Linux on QEMU emulating highbank.
For now I am unable to start in SMP mode. Only one core is activated.
And there is linux backtrace in L2C-310 init.
My command line:
# qemu-system-arm -smp 4 -M highbank -m 1024M -display none -no-reboot
-kernel zImage -initrd r
Hi Wei,
On 2016/2/10 6:59, Wei Huang wrote:
>
> On 02/04/2016 12:51 AM, Shannon Zhao wrote:
>>
>>
>> On 2016/2/4 14:10, Wei Huang wrote:
>>>
>>> On 02/03/2016 07:44 PM, Shannon Zhao wrote:
>
>
>
>>> I reversed the order of edge pulling. The state is 1 according to printk
>>> inside gpio_keys d
Hi,
while testing Kernel 4.4.2 and starting 20 Qemu 2.4.1 virtual machines.
I got those traces and a load of 500 on those system. I was only abler
to recover by sysrq-trigger.
All traces:
INFO: task pvedaemon worke:7470 blocked for more than 120 seconds.
Not tainted 4.4.2+1-ph #1
"echo 0 > /
Hi Paolo,
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Saturday, February 20, 2016 5:48 PM
> To: Gonglei (Arei); qemu-devel@nongnu.org
> Cc: Huangpeng (Peter)
> Subject: Re: [PATCH 0/3] memory: an optimization
>
>
>
>
On 2016-02-19 10:29, Peter Xu wrote:
>> Would be helpful for more convenient import and experiments. E.g. I
>> could quickly through my test setup at them and tell you if they work
>> for it.
>
> I have put codes onto github for better reference:
>
> https://github.com/xzpeter/qemu/tree/vt-d-intr
On 20/02/2016 03:35, Gonglei wrote:
> Perf top tells me qemu_get_ram_ptr consume too much cpu cycles.
>> 22.56% qemu-kvm [.] address_space_translate
>> 13.29% qemu-kvm [.] qemu_get_ram_ptr
>> 4.71% qemu-kvm [.] phys_page_find
>> 4.43% qemu-
- Original Message -
> From: "Jan Kiszka"
> To: "Eduardo Habkost" , "Paolo Bonzini"
>
> Cc: "qemu-devel" , "kvm"
> Sent: Saturday, February 20, 2016 9:09:32 AM
> Subject: kvm: "warning: host doesn't support requested feature:
> CPUID.01H:ECX.x2apic [bit 21]"
>
> Hi all,
>
> I suppo
Hi all,
I suppose 5120901a37 introduced this: qemu with kernel_irqchip=off now
generates these warnings, one per VCPU, during QEMU startup. Is the plan
to live with them until we finally have x2APIC emulation in userspace
(ie. also MSR vmexiting to there), or should we otherwise avoid it?
Thanks,
29 matches
Mail list logo
