On Wed, May 06, 2009 at 01:51:04PM +0300, Avi Kivity wrote:
Gleb Natapov wrote:
On Tue, May 05, 2009 at 02:40:11PM -0400, Glauber Costa wrote:
diff --git a/arch/x86/include/asm/kvm_host.h
b/arch/x86/include/asm/kvm_host.h
index 8e680c3..a49d07b 100644
--- a/arch/x86/include/asm
On Wed, May 06, 2009 at 10:53:06AM -0300, Marcelo Tosatti wrote:
On Tue, May 05, 2009 at 11:16:19PM -0400, Glauber Costa wrote:
When we create a new vcpu, we need to make sure that
all of the state it is going to use (apic state, for example)
already exists. We can do it nicely by making
an
existant vcpu. So we introduce a function that tell us that the vcpu
is already initialized, and is it safe to call the ioctl.
We force the execution of the KVM_SET_LAPIC from within the new
vcpu thread, that will replace this first initialization call.
Signed-off-by: Glauber Costa glom
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 8c0d463..8fd80c1 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -435,6 +435,9 @@ static void *ap_main_loop(void *_env)
kvm_create_vcpu(kvm_context, env-cpu_index);
kvm_qemu_init_env(env);
+/* APIC state creation takes place
Hmm, if the guest runs an infinite emulated 'mov ss', it will keep
toggling the MOV_SS bit, but STI will remain set, so we'll never allow
an interrupt into the guest kernel.
We have no choice but returning both flags, since svm does not differentiate
between them.
But see below for an
for mov ss. pop ss also needs it, but we don't currently
emulate it.
Without this patch, I cannot boot gpxe option roms at vmx machines.
This is described at https://bugzilla.redhat.com/show_bug.cgi?id=494469
Signed-off-by: Glauber Costa glom...@redhat.com
CC: H. Peter Anvin h...@zytor.com
CC: Avi
On Mon, May 04, 2009 at 11:30:58AM +0300, Avi Kivity wrote:
Glauber Costa wrote:
As soon as we call kvm_init_vcpu(), we start the vcpu thread.
However, there is still things that has to be done, as soon
as the new CPUState is created. Examples include initializing the
apic, halting the cpu
On Mon, May 04, 2009 at 05:33:26PM +0300, Avi Kivity wrote:
Glauber Costa wrote:
I'd like to avoid vcpu ioctls from more than one thread, in case we
ever move to a syscall implementation.
Although I don't see exactly what's your point in here.
We're just adding a serialization points
a paravirtual clock, and specialized block/net
drivers, you are already taking advantage
of most of the speed benefits a PV solution can provide you with.
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
--
To unsubscribe
Hello.
Here are a couple of fixes for upstream cpu_hotplug. (currently broken)
After the first patch, it ceases to segfault, and will work with
-no-kvm-irqchip.
The second one fixes the issues with kvm-irqchip
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a
online = works.
Signed-off-by: Glauber Costa glom...@redhat.com
---
qemu/cpu-defs.h |1 +
qemu/hw/pc.c|1 +
qemu/qemu-kvm.c | 11 +++
3 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/qemu/cpu-defs.h b/qemu/cpu-defs.h
index f439ac0..83bddad 100644
--- a/qemu/cpu
has the invert problem.
Signed-off-by: Glauber Costa glom...@redhat.com
---
qemu/hw/apic.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/qemu/hw/apic.c b/qemu/hw/apic.c
index b926508..0ace5cc 100644
--- a/qemu/hw/apic.c
+++ b/qemu/hw/apic.c
@@ -830,7 +830,7 @@ static
Appearently nobody turned this on in a while...
setting apic_debug to something compilable, generates
some errors. This patch fixes it.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kvm/lapic.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch
for mov ss. pop ss also needs it, but we don't currently
emulate it.
Without this patch, I cannot boot gpxe option roms at vmx machines.
This is described at https://bugzilla.redhat.com/show_bug.cgi?id=494469
Signed-off-by: Glauber Costa glom...@redhat.com
CC: H. Peter Anvin h...@zytor.com
CC: Avi
you want
from me.
Since PPC is now supported in upstream QEMU, does it really matter if it
works in qemu-kvm.git?
Yes. There are people (me) who still rely on building everything from
the same source.
It can only be done by the superset (qemu-kvm.git)
--
Glauber Costa.
Free as in Freedom
you want
from me.
Since PPC is now supported in upstream QEMU, does it really matter if it
works in qemu-kvm.git?
Yes. There are people (me) who still rely on building everything from
the same source.
It can only be done by the superset (qemu-kvm.git)
--
Glauber Costa.
Free as in Freedom
-1 if no bit is set */
This is already upstream.
Yeah, and the rest of your patch is totally ok for me.
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
--
To unsubscribe from this list: send the line unsubscribe kvm
On Fri, Apr 17, 2009 at 10:22 AM, Glauber Costa glom...@gmail.com wrote:
Even on sunny days, this collides with QEMU commit #7048. :)
Does Intel specify what non-existent MSRs should return, ie. is your
version still correct if !s-apicbase means that there is actually no
APIC? And does kvm
On Fri, Apr 17, 2009 at 10:53 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
Hi Glauber,
On Fri, Apr 17, 2009 at 01:15:21AM -0400, Glauber Costa wrote:
As KVM cpus runs on threads, it is possible that
we call kvm_load_registers() from a cpu thread, while the
apic has not yet fully
to
initialize).
This patch provides default values to be used for tpr and apic_base,
that will be returned when the apic is not yet properly initialized.
It is aimed at kvm, where the problem exists, but it could equally be
used for qemu too, if there is agreement.
Signed-off-by: Glauber Costa glom
On Tue, Apr 07, 2009 at 09:14:58PM -0700, H. Peter Anvin wrote:
Glauber Costa wrote:
While in real mode, sti does not block interrupts from the subsequent
instruction. This is stated at Intel SDM Volume 2b, page 4-432
I don't see how you're getting that idea from the STI documentation
On Wed, Apr 08, 2009 at 11:16:05AM -0700, H. Peter Anvin wrote:
Glauber Costa wrote:
we currently unblock shadow interrupt state when we skip an instruction,
but failing to do so when we actually emulate one. This blocks interrupts
in key instruction blocks, in particular sti; hlt; sequences
On Wed, Apr 08, 2009 at 11:31:54AM -0700, H. Peter Anvin wrote:
Glauber Costa wrote:
mov ss is a non-issue, since it is executed natively.
In real mode?
it seems so, to me. But I can be wrong. If I am, then I'd
propose the same path I proposed for sti for this.
--
To unsubscribe from
While in real mode, sti does not block interrupts from the subsequent
instruction. This is stated at Intel SDM Volume 2b, page 4-432
Without this patch, I cannot boot gpxe option roms at vmx machines.
This is described at https://bugzilla.redhat.com/show_bug.cgi?id=494469
Signed-off-by: Glauber
=on) and reseting a guest via reboot or system_reset on
monitor and the guest fails to boot. This patch register the correct
region for each option rom.
looks good to me.
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act
://bugzilla.redhat.com/show_bug.cgi?id=494376
It does not fail with cirrus vga, because it is naturally aligned.
This problem does not seem to affect upstream qemu.
Signed-off-by: Glauber Costa glom...@redhat.com
---
qemu/hw/pc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
which to use?
one of them being the userspace linux emulator, and the other, the
system emulator.
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
Almost all tests that are and will be have the common
need to log into the vm, and verify it is alive.
It's currently duplicated across all tests, so rip it
to a common location.
Signed-off-by: Glauber Costa glom...@redhat.com
---
client/tests/kvm_runtest_2/kvm_tests.py | 47
about it crossing more than one segment
border, since the option roms format only save one byte to store
the image size (thus, maximum size = 0xff = 128k = 2 segments)
[ including improvements suggested by malc ]
Signed-off-by: Glauber Costa glom...@redhat.com
---
bios/rombios.c | 33
Almost all tests that are and will be have the common
need to log into the vm, and verify it is alive.
It's currently duplicated across all tests, so rip it
to a common location.
Signed-off-by: Glauber Costa glom...@redhat.com
---
client/tests/kvm_runtest_2/kvm_tests.py | 46
On Tue, Mar 24, 2009 at 10:20 AM, Glauber Costa glom...@redhat.com wrote:
Almost all tests that are and will be have the common
need to log into the vm, and verify it is alive.
It's currently duplicated across all tests, so rip it
to a common location.
screw this.
I just realized I sent
;
+}
+
+if (area_size end - now) {
+return -1;
+}
any reason why you're handling those two differently?
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
--
To unsubscribe from this list: send
On Tue, Mar 24, 2009 at 6:27 PM, Yaniv Kamay yka...@redhat.com wrote:
Glauber Costa wrote:
@@ -1223,12 +1244,44 @@ static int kvm_get_dirty_bitmap_cb(unsigned
long start, unsigned long len,
int kvm_update_dirty_pages_log(void)
{
int r = 0;
+ ram_addr_t now = 0;
+ ram_addr_t
about it crossing more than one segment
border, since the option roms format only save one byte to store
the image size (thus, maximum size = 0xff = 128k = 2 segments)
Signed-off-by: Glauber Costa glom...@redhat.com
---
bios/rombios.c | 33 +++--
1 files changed, 27
, but it was not applied.
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On Wed, Mar 11, 2009 at 3:30 PM, Jochen Roth jr...@linux.vnet.ibm.com wrote:
Glauber Costa wrote:
On Wed, Mar 11, 2009 at 3:10 PM, Jochen Roth jr...@linux.vnet.ibm.com
wrote:
FYI
I just discovered a potential gcc bug which causes kvm-userspace builds
to
break.
I looks like it happens
to all callers. This wasn't noted
before because it is a rather rare scenario.
Instead, just use a normal stack variable. This will
mean that each caller will have it's version written
separatedly. No need for a global counter.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kvm/x86.c
On Thu, Feb 26, 2009 at 08:50:26PM +0100, Arnd Bergmann wrote:
On Thursday 26 February 2009, Glauber Costa wrote:
@@ -548,15 +548,13 @@ static int do_set_msr(struct kvm_vcpu *vcpu, unsigned
index, u64 *data)
static void kvm_write_wall_clock(struct kvm *kvm, gpa_t wall_clock
ppc should compile with upstream qemu code, so, put these
defines in ppc specific code that references kvm functions.
We don put them in config.h in this case, since there are
files (like vl.c) that includes both kvm.h and qemu-kvm.h,
and would break compilation.
Signed-off-by: Glauber Costa
We don't have any kind of kvm support for linux-user targets,
but conditionalizing the inclusion of kvm header make
linux-user compilation break. And we don't have a reason to
prevent that, do we?
Signed-off-by: Glauber Costa glom...@redhat.com
---
qemu/gdbstub.c |2 +-
1 files changed, 1
On Sat, Feb 07, 2009 at 11:43:31AM +0100, Heiko Carstens wrote:
On Fri, 6 Feb 2009 10:46:57 -0500
Glauber Costa glom...@redhat.com wrote:
It is useful to easily grab information about whether or not
we're running on top of a hypervisor. And in case affirmative,
which one
On Mon, Feb 09, 2009 at 03:58:52PM +0200, Avi Kivity wrote:
Gleb Natapov wrote:
For STS register bit are cleared by writing 1 into it.
Patchset looks good; however this is a touchy area. Marcelo or glommer,
can you also review it?
I took a look at the first version, and aside for the
clashes)
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
It is useful to easily grab information about whether or not
we're running on top of a hypervisor. And in case affirmative,
which one.
This patch shows it in /sys/hypervisor (and as a site effect, allow
it to be directly selectable).
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86
This patch is quite close to the last one I've sent.
Only this one goes with chris' suggestion of showing it on
/sys/hypervisor.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at
-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/processor.h |1 +
arch/x86/kernel/cpu/hypervisor.c |3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 091cd88..919c08d 100644
--- a/arch/x86
From: Glauber Costa gco...@redhat.com
It is useful to easily grab information about whether or not
we're running on top of a hypervisor. And in case affirmative,
which one.
This patch shows it in a newly added hypervisor field to cpuinfo.
This seems to me like the best suited place for this.
We
On Thu, Feb 05, 2009 at 10:52:07AM -0800, Chris Wright wrote:
* Glauber Costa (glom...@redhat.com) wrote:
This discussion happened some days ago in kvm list.
We believe it's useful to advertise hypervisor information
somewhere. /proc/cpuinfo appears as one good candidate.
What's wrong
uses
of tsc_khz comply to a per_cpu use. A global tsc_khz does not make sense anyway.
Then we'll have a specific kvm notifier that just forces the guest out
of its execution so we can update
the clock state.
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
function 0x4000, and if you get
ebx = 0x4b4d564b
ecx = 0x564b4d56
edx = 0x4d
you're running KVM.
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
--
To unsubscribe from this list: send the line unsubscribe kvm
On Sat, Jan 31, 2009 at 5:36 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Glauber Costa wrote:
On Sat, Jan 31, 2009 at 10:19 AM, Bryan McLellan b...@loftninjas.org
wrote:
Is there any way to access pv_info from userland? It would be useful
for determining what type of virtualization
On Sat, Jan 31, 2009 at 6:20 PM, Bryan McLellan b...@loftninjas.org wrote:
On Sat, Jan 31, 2009 at 11:55 AM, Glauber Costa glom...@gmail.com wrote:
Since this is a pretty standard mechanism, it may make sense to include this
signature in /proc/cpuinfo if someone is up to writing a patch
-d, for kvm+passthrough.
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
qemu_fopen turned into qemu_fopen_file, and commit b7190d32
fixed it. But then the function turned back into qemu_fopen again,
and we're currently breaking the build.
Marcelo, please revert it.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
On Mon, Jan 26, 2009 at 8:43 AM, Mark McLoughlin mar...@redhat.com wrote:
Signed-off-by: Mark McLoughlin mar...@redhat.com
Why not?
I use it regularly to unequivocally define what kernel tree I'm using.
The default
is often not the right choice.
--
Glauber Costa.
Free as in Freedom
http
it.
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
it is. This allow for both runtime and compile time selection of
what you're running.
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord
Hello fellow 2008-ers, soon to be 2009-ers.
It's time to say goodbye to the year that goes, which I do
by sending the last small series of the year.
This is another hook proposal for kvm, still in the ways to
make tcg optional.
I'm hooking vcpu creation in order to avoid tcg initialization
Allow kvm to override vcpu creation. We need to grab
a minimal amount of code that is shared, but the big
part is highly kvm/tcg specific.
Signed-off-by: Glauber Costa glom...@redhat.com
---
kvm-all.c| 18 ++
kvm.h|2 +-
target-i386/helper.c
We don't need to pass the model string by parameter,
since it ough to be part of the CPUState anyway at
the call time. Also, don't declare it as static,
so kvm can call it in the future.
Signed-off-by: Glauber Costa glom...@redhat.com
---
target-i386/cpu.h|2 ++
target-i386/helper.c
, and I believe
it pays. The tcg mainloop is likely to be different from the
hypervisors ones, since tcg runs all cpus in lockstep. KVM
(and probably xen), will be able to span threads out for its
vcpus.
Signed-off-by: Glauber Costa glom...@redhat.com
---
cpu-exec.c |5 -
kvm-all.c | 50
model. I'm even thinking about changing the name of it
to QEMUCPUModel or whatever. (suggestions welcome)
So default or qemu would be good choices IMHO.
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
--
To unsubscribe from
. The aim of this patch series is
_exactly_ to provide a
way for us (kvm, xen, etc) to do that in a clean way, without
deviating from upstream,
preferably merging your code back.
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act
On Thu, Dec 18, 2008 at 11:41:24AM +0200, Avi Kivity wrote:
Glauber Costa wrote:
record slot used in last lookup. For the common mmio case,
we'll usually access the same memory slot repeatedly.
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -75,16 +75,25 @@ static KVMSlot *kvm_alloc_slot(KVMState
'qemu-kvm' on both, to avoid clash with the base
QEMU binary names.
To the best of my knowledge, Fedora builds a 64-bit qemu for both targets too,
as does upstream.
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act
It's like a shark eating a bunch of small fishes:
in some situations (vga linear frame buffer mapping,
for example), we need to register a new slot in place
of older, smaller ones. This patch handles this case
Signed-off-by: Glauber Costa glom...@redhat.com
---
kvm-all.c | 10 ++
1
management significantly more complex.
Signed-off-by: Glauber Costa glom...@redhat.com
---
hw/cirrus_vga.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index 83c5f40..e4f08ef 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
goal is to use function pointers in
a way very close to which QEMUAccel used to be.
Signed-off-by: Glauber Costa glom...@redhat.com
---
exec.c| 13 +++--
kvm-all.c | 44
kvm.h |2 ++
3 files changed, 53 insertions(+), 6 deletions
record slot used in last lookup. For the common mmio case,
we'll usually access the same memory slot repeatedly.
Signed-off-by: Glauber Costa glom...@redhat.com
---
kvm-all.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index a94ee57
. (kvm_get_physical_page_desc)
Signed-off-by: Glauber Costa glom...@redhat.com
---
exec.c| 44 +---
kvm-all.c | 13 +
kvm.h |2 ++
3 files changed, 44 insertions(+), 15 deletions(-)
diff --git a/exec.c b/exec.c
index 9a52275..b058501 100644
Same old story, but addressing immediate concerns.
I'm not handling the overflow issue avi raised, since
it's a separate deal. We can address it in a separate patch
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More
record slot used in last lookup. For the common mmio case,
we'll usually access the same memory slot repeatedly.
Signed-off-by: Glauber Costa glom...@redhat.com
---
kvm-all.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index b432e14
. (kvm_get_physical_page_desc)
Signed-off-by: Glauber Costa glom...@redhat.com
---
exec.c| 44 +---
kvm-all.c | 13 +
kvm.h |2 ++
3 files changed, 44 insertions(+), 15 deletions(-)
diff --git a/exec.c b/exec.c
index d5c88b1..fe0591b 100644
Hi,
This series replaces some of the tcg memory handling functions,
like cpu_physical_memory_rw and cpu_register_physical_memory
by kvm versions.
I believe this approach pays, because it'll reduce the dependency
that kvm, xen, etc have on the tcg part of qemu. My mid term goal
with it is to be
goal is to use function pointers in
a way very close to which QEMUAccel used to be.
Signed-off-by: Glauber Costa glom...@redhat.com
---
exec.c| 13 +++--
kvm-all.c | 39 +++
kvm.h |2 ++
3 files changed, 48 insertions(+), 6 deletions
introduce cpu_physical_memory_do_io, which handles
the mmio part of cpu_physical_memory_rw. KVM can use
it to do mmio, since mmio is essentially the same for
both KVM and tcg.
Signed-off-by: Glauber Costa glom...@redhat.com
---
cpu-all.h |2 +
exec.c| 89
On Wed, Dec 17, 2008 at 02:56:05PM -0600, Anthony Liguori wrote:
Glauber Costa wrote:
This patch introduces a kvm version of cpu_physical_memory_rw.
The main motivation is to bypass tcg version, which contains
tcg-specific code, as well as data structures not used by kvm,
such as l1_phys_map
This is just a tiny nitpick I came across while hacking on other stuff.
It reduces the code duplication, hopefully in a good way for other eyes
too.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Code for all versions of notdirty_mem_write are quite alike.
Rewrite it as a generator macro.
Signed-off-by: Glauber Costa [EMAIL PROTECTED]
---
exec.c | 66 ---
1 files changed, 17 insertions(+), 49 deletions(-)
diff --git a/exec.c
to release compatibility code
for people running older kernels for this bug fix specifically
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message
kvm header has to be always included.
Signed-off-by: Glauber Costa [EMAIL PROTECTED]
---
qemu/hw/acpi.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index 12f4fce..5458e54 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -24,9 +24,7
garbage
clobbering a big portion of the bar.
After this patch, this garbage is gone.
Signed-off-by: Glauber Costa [EMAIL PROTECTED]
---
hw/cirrus_vga.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index e0cf458..5690719 100644
a different piece of memory.
In this patch, we destroy rmaps, and vfree() the
pointers that used to hold the dirty bitmap, rmap
and lpage_info structures.
qemu's VGA optimization won't work without this patch
Signed-off-by: Glauber Costa [EMAIL PROTECTED]
---
virt/kvm/kvm_main.c |5 -
1 files
to
the iret instruction.
This fixes a bug that prevents slackware (and possibly win2k, untested)
to boot.
Signed-off-by: Glauber Costa [EMAIL PROTECTED]
---
extboot/extboot.S | 52 ++--
1 files changed, 26 insertions(+), 26 deletions(-)
diff --git
to
the iret instruction.
This fixes a bug that prevents slackware (and possibly win2k, untested)
to boot.
Signed-off-by: Glauber Costa [EMAIL PROTECTED]
---
extboot/extboot.S | 52 ++--
1 files changed, 26 insertions(+), 26 deletions(-)
diff --git
kvmversion' or some other
new command.
I believe it fits nicely into info kvm. Instead of enabled/disabled,
we could answer
disabled or kvm-whatever
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
--
To unsubscribe from
-nmemslots = mem-slot + 1;
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
On Fri, Nov 21, 2008 at 3:10 PM, Marcelo Tosatti [EMAIL PROTECTED] wrote:
Hi Jan,
On Fri, Nov 21, 2008 at 08:54:56AM +0100, Jan Kiszka wrote:
Eduardo Habkost wrote:
On Thu, Nov 20, 2008 at 12:22:53PM -0200, Eduardo Habkost wrote:
Hi,
When using a kvm.git kernel as host, I am getting
a different piece of memory.
In this patch, we destroy rmaps, and vfree() the
pointers that used to hold the dirty bitmap, rmap
and lpage_info structures.
Signed-off-by: Glauber Costa [EMAIL PROTECTED]
---
virt/kvm/kvm_main.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff
Currently, we only set the KVM paravirt signature in case
of CONFIG_KVM_GUEST. However, it is possible to have it turned
off, while CONFIG_KVM_CLOCK is turned on. This is also a paravirt
case, and should be shown accordingly.
Signed-off-by: Glauber Costa [EMAIL PROTECTED]
---
arch/x86/kernel
On Thu, Nov 20, 2008 at 02:56:00AM +0100, Marcelo Tosatti wrote:
On Wed, Nov 19, 2008 at 10:53:27PM +0100, Roland Lammel wrote:
Actually it just happenend again with the host running kvm-79. Host
CPU is at 100% but I'm still able to login (it recovered from the
first hang). But I'm not
On Wed, Nov 19, 2008 at 09:55:10AM -0600, Anthony Liguori wrote:
Glauber Costa wrote:
Currently, kvm only sets new.userspace_addr in slots
that were just allocated. This is not the intended behaviour,
and actually breaks when we try to use the slots to implement
aliases, for example.
Cirrus
On Wed, Nov 19, 2008 at 12:51:00PM -0600, Anthony Liguori wrote:
But the problem still exists even with this code. I checked.
So if you have something working without modifying the kernel, can you
post it?
Regards,
Anthony Liguori
Ok, how do you feel about this one?
My proposal is to
address to different locations
until the whole screen is filled.
The solution is to assign new.userspace_addr no matter what,
so we can be sure that whenever the guest changes this field,
it sees the change being reflected in the code.
Signed-off-by: Glauber Costa [EMAIL PROTECTED]
---
virt/kvm
in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
--
To unsubscribe from this list: send the line unsubscribe kvm
to a different
target, we create an essential ambiguity that brings no value at
the cost of a lot of confusion. Right now this confusion
manifests itself as a BUG() triggered in the rmaps code path.
Signed-off-by: Glauber Costa [EMAIL PROTECTED]
---
arch/x86/kvm/x86.c | 12 ++--
1 files changed, 10
of fine grained locking. And we don't really know how the
code will look like
after that. It can very well change completely, rendering this work as
totally void.
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
--
To unsubscribe
historical.
--
Glauber Costa.
Free as in Freedom
http://glommer.net
The less confident you are, the more serious you have to act.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
.
If you think they are all reasonable, maybe we can send them all as a series.
Thanks,
Nick
On Thu, Nov 06, 2008 at 06:58:26PM -0200, Glauber Costa wrote:
Current vmalloc restart search for a free area in case we
can't find one. The reason is there are areas which are lazily
freed
701 - 800 of 951 matches
Mail list logo
