Il 12/10/2013 21:05, Michael Tokarev ha scritto:
I considered doing it there initially, but decided to add it
to the other place, because that's where virtfs variable
is set. The place you're referring to will need to have a
condition `if' based on $virtfs value.
It's harmless to create a
Currently 64-bit PCI BARs are unconditionally mapped by BIOS right
over 4G + RamSizeOver4G location, which doesn't allow to reserve
extra space before 64-bit PCI window. For memory hotplug an extra
RAM space might be reserved after present 64-bit RAM end and BIOS
should map 64-bit PCI BARs after
On Sun, Oct 13, 2013 at 02:13:44PM +0200, Igor Mammedov wrote:
Currently 64-bit PCI BARs are unconditionally mapped by BIOS right
over 4G + RamSizeOver4G location, which doesn't allow to reserve
extra space before 64-bit PCI window. For memory hotplug an extra
RAM space might be reserved after
Please try -global mc146818rtc.lost_tick_policy=slew.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1174654
Title:
qemu-system-x86_64 takes 100% CPU after host machine resumed from
suspend to
On Sun, 13 Oct 2013 15:31:23 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Oct 13, 2013 at 02:13:44PM +0200, Igor Mammedov wrote:
Currently 64-bit PCI BARs are unconditionally mapped by BIOS right
over 4G + RamSizeOver4G location, which doesn't allow to reserve
extra space before
On Sun, Oct 13, 2013 at 03:31:23PM +0300, Michael S. Tsirkin wrote:
On Sun, Oct 13, 2013 at 02:13:44PM +0200, Igor Mammedov wrote:
Currently 64-bit PCI BARs are unconditionally mapped by BIOS right
over 4G + RamSizeOver4G location, which doesn't allow to reserve
extra space before 64-bit
On Mon, 2013-09-30 at 22:20 +0100, Richard Purdie wrote:
This is a combination of bug report and patch. I'm not sure if you'll want to
fix it
like this but it illustrates the problem and should be easy to fix based on
this.
When we restore the mxcsr register with FXRSTOR, we need to
On Sun, Oct 13, 2013 at 05:11:54PM +0200, Igor Mammedov wrote:
On Sun, 13 Oct 2013 15:31:23 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Oct 13, 2013 at 02:13:44PM +0200, Igor Mammedov wrote:
Currently 64-bit PCI BARs are unconditionally mapped by BIOS right
over 4G +
On Sun, 13 Oct 2013 18:59:20 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Oct 13, 2013 at 05:11:54PM +0200, Igor Mammedov wrote:
On Sun, 13 Oct 2013 15:31:23 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Oct 13, 2013 at 02:13:44PM +0200, Igor Mammedov wrote:
On Sun, Oct 13, 2013 at 06:23:28PM +0200, Igor Mammedov wrote:
On Sun, 13 Oct 2013 18:59:20 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Oct 13, 2013 at 05:11:54PM +0200, Igor Mammedov wrote:
On Sun, 13 Oct 2013 15:31:23 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Oct 07, 2013 at 12:34:46PM +0300, Michael S. Tsirkin wrote:
This code can also be found here:
git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git acpi
No new issues has been raised in a week, I assume
it's ok to merge now. Will apply around tomorrow.
On Sun, 13 Oct 2013 19:46:09 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Oct 13, 2013 at 06:23:28PM +0200, Igor Mammedov wrote:
On Sun, 13 Oct 2013 18:59:20 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Oct 13, 2013 at 05:11:54PM +0200, Igor Mammedov wrote:
On
On Sun, 13 Oct 2013 19:33:19 +0200
Igor Mammedov imamm...@redhat.com wrote:
On Sun, 13 Oct 2013 19:46:09 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Oct 13, 2013 at 06:23:28PM +0200, Igor Mammedov wrote:
On Sun, 13 Oct 2013 18:59:20 +0300
Michael S. Tsirkin m...@redhat.com
On Sun, Oct 13, 2013 at 08:19:16PM +0200, Igor Mammedov wrote:
On Sun, 13 Oct 2013 19:33:19 +0200
Igor Mammedov imamm...@redhat.com wrote:
On Sun, 13 Oct 2013 19:46:09 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Oct 13, 2013 at 06:23:28PM +0200, Igor Mammedov wrote:
On
On Sun, Oct 13, 2013 at 07:33:19PM +0200, Igor Mammedov wrote:
On Sun, 13 Oct 2013 19:46:09 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Oct 13, 2013 at 06:23:28PM +0200, Igor Mammedov wrote:
On Sun, 13 Oct 2013 18:59:20 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Oct 07, 2013 at 12:21:26PM +0300, Michael S. Tsirkin wrote:
This is on top of patchset generating ACPI tables in qemu.
Please review and consider for 1.7.
No comments, I assume it's ok to merge this.
Changes from v2:
- split new code out to a separate file: acpi/pcihp.c
Cc'ing qemu-sta...@nongnu.org.
On Fri, 10/11 19:48, Fam Zheng wrote:
An extra 'p++' after while loop when *p == '\n' will move p to unknown
data position, risking parsing junk data or memory access violation.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Fam Zheng f...@redhat.com
---
Greetings!
I am new to kvm qemu and are writing a python script to get the number of
pre-copy cycles during a remote vm migration given memory size M of a VM in
MB, the page dirty rate R of a vm in MB/s. My question is on
how to get the page dirty rate. Does kvm qemu provide a dirty page
On 09/30/2013 09:30 PM, Alexander Graf wrote:
On 27.09.2013, at 10:05, Alexey Kardashevskiy wrote:
IBM POWERPC processors encode PVR as a CPU family in higher 16 bits and
a CPU version in lower 16 bits. Since there is no significant change
in behavior between versions, there is no point to
19 matches
Mail list logo
