On 08/04/2010 05:44 AM, Mohammed Gamal wrote:
This adds support for int instructions to the emulator
@@ -2963,6 +3025,21 @@ special_insn:
if (rc != X86EMUL_CONTINUE)
goto done;
break;
+ case 0xcc: /* int3 */
+
On (Tue) Aug 03 2010 [11:37:38], Nirmal Guhan wrote:
Thanks. Will this work if the guest or host are different combo
Yes, it would.
Amit
--
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
On 08/04/2010 08:39 AM, André Weidemann wrote:
Hi,
I recently upgraded my machine from Ubuntu 9.10 to 10.4 (x86_64).
Ever since I upgraded my machine I cannot get qemu-kvm to start again.
I did not install the kvm package provided by Ubuntu. Instead I pulled
todays git from
On 04.08.2010 08:48, Avi Kivity wrote:
On 08/04/2010 08:39 AM, André Weidemann wrote:
Hi,
I recently upgraded my machine from Ubuntu 9.10 to 10.4 (x86_64).
Ever since I upgraded my machine I cannot get qemu-kvm to start again.
I did not install the kvm package provided by Ubuntu. Instead I
On 08/04/2010 09:55 AM, André Weidemann wrote:
On 04.08.2010 08:48, Avi Kivity wrote:
On 08/04/2010 08:39 AM, André Weidemann wrote:
Hi,
I recently upgraded my machine from Ubuntu 9.10 to 10.4 (x86_64).
Ever since I upgraded my machine I cannot get qemu-kvm to start again.
I did not install
mmu_shrink() should attempt to free @nr_to_scan entries.
Signed-off-by: Lai Jiangshan la...@cn.fujitsu.com
---
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 9c69725..1034373 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3138,37 +3138,51 @@ static int mmu_shrink(struct
Use SrcAcc to simplify stos decoding.
Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com
---
arch/x86/kvm/emulate.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index f03ff26..4624b11 100644
--- a/arch/x86/kvm/emulate.c
On 04.08.2010 09:05, Avi Kivity wrote:
On 08/04/2010 09:55 AM, André Weidemann wrote:
On 04.08.2010 08:48, Avi Kivity wrote:
On 08/04/2010 08:39 AM, André Weidemann wrote:
Hi,
I recently upgraded my machine from Ubuntu 9.10 to 10.4 (x86_64).
Ever since I upgraded my machine I cannot get
This patch change to disable writeback when decode dest
operand if the dest type is ImplicitOps or not specified.
Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com
---
arch/x86/kvm/emulate.c | 23 ++-
1 files changed, 6 insertions(+), 17 deletions(-)
diff --git
Using SrcOne for instruction d0/d1 decoding.
Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com
---
arch/x86/kvm/emulate.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 31c33f4..1ce3c4f 100644
---
Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com
---
arch/x86/kvm/emulate.c | 50 ---
1 files changed, 21 insertions(+), 29 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 1ce3c4f..d197b46 100644
---
Hi,
(1) -M somethingold. PCI devices don't have a pci rom bar then by
default because they didn't not have one in older qemu versions,
so we need some other way to pass the option rom to seabios.
What did we do back then? before we had the fwcfg interface?
Have qemu instead of
On 08/03/2010 11:34 PM, Anthony Liguori wrote:
Comparing (from personal experience) the complexity of the Windows
drivers for Xen and virtio shows that it's not a bad idea at all.
Not quite sure what you're suggesting, but I could have been clearer.
Instead of having virtio-blk where a virtio
On 08/04/2010 10:56 AM, Gerd Hoffmann wrote:
Hi,
(1) -M somethingold. PCI devices don't have a pci rom bar then by
default because they didn't not have one in older qemu versions,
so we need some other way to pass the option rom to seabios.
What did we do back then? before we had the
On Tuesday 03 Aug 2010 21:57:48 Yinghai Lu wrote:
On Tue, Aug 3, 2010 at 8:59 AM, Tvrtko Ursulin
tvrtko.ursu...@sophos.com wrote:
On Tuesday 03 Aug 2010 16:17:20 Tvrtko Ursulin wrote:
On Tuesday 03 Aug 2010 15:57:03 Tvrtko Ursulin wrote:
On Tuesday 03 Aug 2010 15:51:08 Avi Kivity wrote:
On Tue, Aug 3, 2010 at 11:04 PM, Nirmal Guhan vavat...@gmail.com wrote:
I am seeing a performance degradation while using libvirt to start my
vm (kvm). vm is fedora 12 and host is also fedora 12, both with
2.6.32.10-90.fc12.i686. Here are the statistics from iperf :
From VM: [ 3] 0.0-30.0
On 08/04/2010 10:57 AM, Paolo Bonzini wrote:
On 08/03/2010 11:34 PM, Anthony Liguori wrote:
Comparing (from personal experience) the complexity of the Windows
drivers for Xen and virtio shows that it's not a bad idea at all.
Not quite sure what you're suggesting, but I could have been
On 08/03/2010 10:13 PM, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 09:43:39PM +0300, Avi Kivity wrote:
libguestfs does not depend on an x86 architectural feature.
qemu-system-x86_64 emulates a PC, and PCs don't have -kernel. We
should discourage people from depending on this interface
Group 8 instruction, BT[S|R|C] should be mask as BitOp.
Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com
---
arch/x86/kvm/emulate.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index d197b46..eba5a67 100644
---
On Wed, Aug 04, 2010 at 11:17:28AM +0300, Avi Kivity wrote:
On 08/04/2010 10:56 AM, Gerd Hoffmann wrote:
Hi,
(1) -M somethingold. PCI devices don't have a pci rom bar then by
default because they didn't not have one in older qemu versions,
so we need some other way to pass the option rom
On Wednesday 04 August 2010, Dong, Eddie wrote:
Arnd Bergmann wrote:
On Friday 30 July 2010 17:51:52 Shirley Ma wrote:
I think it should be less duplicated code in the kernel if we use
macvtap to support what media passthrough driver here. Since macvtap
has support virtio_net head and
Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com
---
arch/x86/kvm/emulate.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index eba5a67..c05a5d7 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@
On 08/04/2010 01:18 AM, Tvrtko Ursulin wrote:
On Tuesday 03 Aug 2010 21:57:48 Yinghai Lu wrote:
On Tue, Aug 3, 2010 at 8:59 AM, Tvrtko Ursulin
tvrtko.ursu...@sophos.com wrote:
On Tuesday 03 Aug 2010 16:17:20 Tvrtko Ursulin wrote:
On Tuesday 03 Aug 2010 15:57:03 Tvrtko Ursulin wrote:
On
On Wednesday 04 Aug 2010 10:05:36 Yinghai Lu wrote:
On 08/04/2010 01:18 AM, Tvrtko Ursulin wrote:
On Tuesday 03 Aug 2010 21:57:48 Yinghai Lu wrote:
On Tue, Aug 3, 2010 at 8:59 AM, Tvrtko Ursulin
tvrtko.ursu...@sophos.com wrote:
On Tuesday 03 Aug 2010 16:17:20 Tvrtko Ursulin wrote:
On
On Wednesday 04 Aug 2010 10:16:08 Tvrtko Ursulin wrote:
On Wednesday 04 Aug 2010 10:05:36 Yinghai Lu wrote:
On 08/04/2010 01:18 AM, Tvrtko Ursulin wrote:
On Tuesday 03 Aug 2010 21:57:48 Yinghai Lu wrote:
On Tue, Aug 3, 2010 at 8:59 AM, Tvrtko Ursulin
tvrtko.ursu...@sophos.com wrote:
On 08/04/10 10:17, Avi Kivity wrote:
On 08/04/2010 10:56 AM, Gerd Hoffmann wrote:
Hi,
(1) -M somethingold. PCI devices don't have a pci rom bar then by
default because they didn't not have one in older qemu versions,
so we need some other way to pass the option rom to seabios.
What did we
On Wed, Aug 04, 2010 at 08:54:35AM +0300, Avi Kivity wrote:
On 08/04/2010 01:06 AM, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 10:24:41PM +0300, Avi Kivity wrote:
Why do we need to transfer roms? These are devices on the memory
bus or pci bus, it just needs to be there at the right
On Wed, Aug 04, 2010 at 10:24:28AM +0100, Richard W.M. Jones wrote:
On Wed, Aug 04, 2010 at 08:54:35AM +0300, Avi Kivity wrote:
On 08/04/2010 01:06 AM, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 10:24:41PM +0300, Avi Kivity wrote:
Why do we need to transfer roms? These are devices
On 08/04/2010 11:01 AM, Wei Yongjun wrote:
Signed-off-by: Wei Yongjunyj...@cn.fujitsu.com
---
arch/x86/kvm/emulate.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index eba5a67..c05a5d7 100644
---
On 08/04/2010 02:16 AM, Tvrtko Ursulin wrote:
On Wednesday 04 Aug 2010 10:05:36 Yinghai Lu wrote:
On 08/04/2010 01:18 AM, Tvrtko Ursulin wrote:
On Tuesday 03 Aug 2010 21:57:48 Yinghai Lu wrote:
On Tue, Aug 3, 2010 at 8:59 AM, Tvrtko Ursulin
tvrtko.ursu...@sophos.com wrote:
On Tuesday 03 Aug
On Wed, Aug 04, 2010 at 10:16:08AM +0100, Tvrtko Ursulin wrote:
On Wednesday 04 Aug 2010 10:05:36 Yinghai Lu wrote:
On 08/04/2010 01:18 AM, Tvrtko Ursulin wrote:
On Tuesday 03 Aug 2010 21:57:48 Yinghai Lu wrote:
On Tue, Aug 3, 2010 at 8:59 AM, Tvrtko Ursulin
On 08/04/2010 11:01 AM, Wei Yongjun wrote:
Signed-off-by: Wei Yongjunyj...@cn.fujitsu.com
---
arch/x86/kvm/emulate.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index eba5a67..c05a5d7 100644
---
Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com
---
arch/x86/kvm/emulate.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index eba5a67..74008ed 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@
On 08/04/2010 10:27 AM, Wei Yongjun wrote:
Group 8 instruction, BT[S|R|C] should be mask as BitOp.
Signed-off-by: Wei Yongjunyj...@cn.fujitsu.com
---
arch/x86/kvm/emulate.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/emulate.c
On Wednesday 04 Aug 2010 10:34:28 Yinghai Lu wrote:
[snip]
so your host is 32bit or 64bit?
Host is 64-bit.
can you use working 32bit guest to dump mptable like debug apic=debug
acpi=off earlyprintk... ?
This? From 2.6.34...
[0.00] Using APIC driver default
[0.00] Intel
On 08/04/2010 11:37 AM, Wei Yongjun wrote:
Signed-off-by: Wei Yongjunyj...@cn.fujitsu.com
---
arch/x86/kvm/emulate.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index eba5a67..74008ed 100644
---
On 08/04/2010 12:24 PM, Richard W.M. Jones wrote:
Just like the initrd?
There isn't enough address space for a 100MB initrd in ROM.
Because of limits of the original PC, sure, where you had to fit
everything in 0xa-0xf or whatever it was.
But this isn't a real PC.
You can map the
On 08/04/2010 10:38 AM, André Weidemann wrote:
Please enable ftrace:
# mount -t debugfs debugfs /sys/kernel/debug
# cd /sys/kernel/debug/tracing
# echo 10 buffer_size_kb
# echo kvm set_event
# echo 1 tracing on
run the guest and kill qemu immediately when you get to the blank screen
Gleb Natapov g...@redhat.com writes:
On Wed, Aug 04, 2010 at 10:16:08AM +0100, Tvrtko Ursulin wrote:
Not the tip but 2.6.35 with earlyprintk=ttyS0,115200:
[0.00] Processor #0 (Bootup-CPU)
[0.00] I/O APIC #1 Version 17 at 0xFEC0.
[0.00] BUG: unable to handle
On Tue, 2010-07-27 at 07:55 +0300, Michael S. Tsirkin wrote:
Peter, could you please indicate whether you think this is the way to
go, too?
I really dislike it, as you indicated, you now want priority too..
It seems the problem is that we normally don't consider work done by
kernel threads
On Wednesday 04 Aug 2010 11:37:43 Eric W. Biederman wrote:
Gleb Natapov g...@redhat.com writes:
On Wed, Aug 04, 2010 at 10:16:08AM +0100, Tvrtko Ursulin wrote:
Not the tip but 2.6.35 with earlyprintk=ttyS0,115200:
[0.00] Processor #0 (Bootup-CPU)
[0.00] I/O APIC #1
On 04.08.2010 12:31, Avi Kivity wrote:
On 08/04/2010 10:38 AM, André Weidemann wrote:
Please enable ftrace:
# mount -t debugfs debugfs /sys/kernel/debug
# cd /sys/kernel/debug/tracing
# echo 10 buffer_size_kb
# echo kvm set_event
# echo 1 tracing on
run the guest and kill qemu
On 08/04/2010 02:22 PM, André Weidemann wrote:
On 04.08.2010 12:31, Avi Kivity wrote:
On 08/04/2010 10:38 AM, André Weidemann wrote:
Please enable ftrace:
# mount -t debugfs debugfs /sys/kernel/debug
# cd /sys/kernel/debug/tracing
# echo 10 buffer_size_kb
# echo kvm set_event
# echo
On Wed, Aug 04, 2010 at 12:52:23PM +0300, Avi Kivity wrote:
On 08/04/2010 12:24 PM, Richard W.M. Jones wrote:
Just like the initrd?
There isn't enough address space for a 100MB initrd in ROM.
Because of limits of the original PC, sure, where you had to fit
everything in 0xa-0xf or
On 08/04/2010 02:33 PM, Richard W.M. Jones wrote:
I'm only allocating 500MB of RAM, so there's easily enough space to
put a large ROM, with tons of room for growth (of both RAM and ROM).
Yes, even real hardware has done this. The Weitek math copro mapped
itself in at physical memory addresses
This adds support for int instructions to the emulator
Signed-off-by: Mohammed Gamal m.gamal...@gmail.com
---
arch/x86/kvm/emulate.c | 78
1 files changed, 78 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/emulate.c
If a nop instruction is encountered, we jump directly to the done label.
This skip updating rip. Break from the switch case instead
Signed-off-by: Mohammed Gamal m.gamal...@gmail.com
---
arch/x86/kvm/emulate.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
On 04.08.2010 13:29, Avi Kivity wrote:
On 08/04/2010 02:22 PM, André Weidemann wrote:
On 04.08.2010 12:31, Avi Kivity wrote:
On 08/04/2010 10:38 AM, André Weidemann wrote:
Please enable ftrace:
# mount -t debugfs debugfs /sys/kernel/debug
# cd /sys/kernel/debug/tracing
# echo 10
On Wed, Jun 16, 2010, Gleb Natapov wrote about Re: [PATCH 13/24] Implement
VMREAD and VMWRITE:
+ set_rflags_to_vmx_fail_valid(vcpu);
+ vmcs_write32(VM_INSTRUCTION_ERROR, 12);
VM_INSTRUCTION_ERROR is read only and when do you transfer it to vmcs12
anyway?.
I think
On Wed, Aug 04, 2010 at 12:33:18PM +0100, Richard W.M. Jones wrote:
On Wed, Aug 04, 2010 at 12:52:23PM +0300, Avi Kivity wrote:
On 08/04/2010 12:24 PM, Richard W.M. Jones wrote:
Just like the initrd?
There isn't enough address space for a 100MB initrd in ROM.
Because of limits of the
On Tue, Aug 3, 2010 at 5:14 PM, Avi Kivity a...@redhat.com wrote:
On 08/03/2010 05:57 PM, John Leach wrote:
On Tue, 2010-08-03 at 17:44 +0300, Avi Kivity wrote:
On 08/03/2010 05:40 PM, John Leach wrote:
dd if=/dev/mapper/zero of=/dev/null bs=8k count=100 iflag=direct
819200 bytes
On 08/04/2010 02:57 AM, Paolo Bonzini wrote:
On 08/03/2010 11:34 PM, Anthony Liguori wrote:
Comparing (from personal experience) the complexity of the Windows
drivers for Xen and virtio shows that it's not a bad idea at all.
Not quite sure what you're suggesting, but I could have been
I managed to get libvirtd out of the loop. I'm starting the vm with:
qemu-kvm -S -M fedora-13 -enable-kvm -m 2048 -smp 2,sockets=1,cores=2,threads=1
-name test -uuid 5ffc03bf-3562-1c90-9543-a64b2416a4a1 -nodefaults -chardev
socket,id=monitor,path=/var/lib/libvirt/qemu/test.monitor,server,nowait
On 08/04/2010 04:24 AM, Richard W.M. Jones wrote:
On Wed, Aug 04, 2010 at 08:54:35AM +0300, Avi Kivity wrote:
On 08/04/2010 01:06 AM, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 10:24:41PM +0300, Avi Kivity wrote:
Why do we need to transfer roms? These are devices
On 08/04/2010 03:17 AM, Avi Kivity wrote:
For playing games, there are three options:
- existing fwcfg
- fwcfg+dma
- put roms in 4GB-2MB (or whatever we decide the flash size is) and
have the BIOS copy them
Existing fwcfg is the least amount of work and probably satisfactory
for isapc.
On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote:
On 08/04/2010 03:17 AM, Avi Kivity wrote:
For playing games, there are three options:
- existing fwcfg
- fwcfg+dma
- put roms in 4GB-2MB (or whatever we decide the flash size is)
and have the BIOS copy them
Existing fwcfg is
On 08/04/2010 08:07 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote:
On 08/04/2010 03:17 AM, Avi Kivity wrote:
For playing games, there are three options:
- existing fwcfg
- fwcfg+dma
- put roms in 4GB-2MB (or whatever we decide the flash size
On Wed, Aug 04, 2010 at 04:07:09PM +0300, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote:
On 08/04/2010 03:17 AM, Avi Kivity wrote:
For playing games, there are three options:
- existing fwcfg
- fwcfg+dma
- put roms in 4GB-2MB (or whatever we decide
On Wed, Aug 04, 2010 at 08:15:04AM -0500, Anthony Liguori wrote:
On 08/04/2010 08:07 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote:
On 08/04/2010 03:17 AM, Avi Kivity wrote:
For playing games, there are three options:
- existing fwcfg
- fwcfg+dma
-
On Wed, Aug 04, 2010 at 02:24:08PM +0100, Richard W.M. Jones wrote:
On Wed, Aug 04, 2010 at 08:15:04AM -0500, Anthony Liguori wrote:
On 08/04/2010 08:07 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote:
On 08/04/2010 03:17 AM, Avi Kivity wrote:
For
On Wed, Aug 04, 2010 at 02:22:29PM +0100, Richard W.M. Jones wrote:
On Wed, Aug 04, 2010 at 04:07:09PM +0300, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote:
On 08/04/2010 03:17 AM, Avi Kivity wrote:
For playing games, there are three options:
-
On Wed, Aug 04, 2010 at 08:15:04AM -0500, Anthony Liguori wrote:
On 08/04/2010 08:07 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote:
On 08/04/2010 03:17 AM, Avi Kivity wrote:
For playing games, there are three options:
- existing fwcfg
- fwcfg+dma
-
On Wed, Jun 16, 2010, Gleb Natapov wrote about Re: [PATCH 13/24] Implement
VMREAD and VMWRITE:
On Mon, Jun 14, 2010 at 12:36:02PM +0300, Avi Kivity wrote:
vmread doesn't support 64-bit writes to memory outside long mode, so
you'll have to truncate the write.
I think you'll be better off
On 08/04/2010 08:34 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 08:15:04AM -0500, Anthony Liguori wrote:
On 08/04/2010 08:07 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote:
On 08/04/2010 03:17 AM, Avi Kivity wrote:
For
On Wed, Aug 04, 2010 at 08:52:44AM -0500, Anthony Liguori wrote:
On 08/04/2010 08:34 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 08:15:04AM -0500, Anthony Liguori wrote:
On 08/04/2010 08:07 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote:
On
On Wed, 2010-08-04 at 14:53 +0200, Gerrit van der Kolk wrote:
I managed to get libvirtd out of the loop. I'm starting the vm with:
qemu-kvm -S -M fedora-13 -enable-kvm -m 2048 -smp
2,sockets=1,cores=2,threads=1 -name test -uuid
5ffc03bf-3562-1c90-9543-a64b2416a4a1 -nodefaults -chardev
On 08/04/2010 09:00 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 08:52:44AM -0500, Anthony Liguori wrote:
On 08/04/2010 08:34 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 08:15:04AM -0500, Anthony Liguori wrote:
On 08/04/2010 08:07 AM, Gleb Natapov wrote:
On
On 08/04/2010 08:26 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 02:24:08PM +0100, Richard W.M. Jones wrote:
On Wed, Aug 04, 2010 at 08:15:04AM -0500, Anthony Liguori wrote:
On 08/04/2010 08:07 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony
On 08/04/2010 04:00 PM, Gleb Natapov wrote:
Maybe we're just being too fancy here.
We could rewrite -kernel/-append/-initrd to just generate a floppy
image in RAM, and just boot from floppy.
May be. Can floppy be 100M?
Well, in theory you can have 16384 bytes/sector, 256 tracks, 255
On Wed, Aug 04, 2010 at 09:14:01AM -0500, Anthony Liguori wrote:
Unmapping device and mapping it at the same place is easy. Enumerating
pci devices from multiboot.bin looks like unneeded churn though.
Maybe we're just being too fancy here.
We could rewrite -kernel/-append/-initrd to just
On Wed, Aug 04, 2010 at 09:22:22AM -0500, Anthony Liguori wrote:
On 08/04/2010 08:26 AM, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 02:24:08PM +0100, Richard W.M. Jones wrote:
On Wed, Aug 04, 2010 at 08:15:04AM -0500, Anthony Liguori wrote:
On 08/04/2010 08:07 AM, Gleb Natapov wrote:
On Wed,
On 08/04/2010 09:22 AM, Paolo Bonzini wrote:
On 08/04/2010 04:00 PM, Gleb Natapov wrote:
Maybe we're just being too fancy here.
We could rewrite -kernel/-append/-initrd to just generate a floppy
image in RAM, and just boot from floppy.
May be. Can floppy be 100M?
Well, in theory you can
On 08/04/2010 09:38 AM, Gleb Natapov wrote:
But even if it wasn't it can potentially create havoc. I think we
currently believe that the northbridge likely never forwards RAM
access to a device so this doesn't fit how hardware would work.
Good point.
More importantly, BIOSes and
On 08/03/10 12:43, Avi Kivity wrote:
libguestfs does not depend on an x86 architectural feature.
qemu-system-x86_64 emulates a PC, and PCs don't have -kernel. We should
discourage people from depending on this interface for production use.
That is a feature of qemu - and an important one
On 08/04/2010 09:51 AM, David S. Ahern wrote:
On 08/03/10 12:43, Avi Kivity wrote:
libguestfs does not depend on an x86 architectural feature.
qemu-system-x86_64 emulates a PC, and PCs don't have -kernel. We should
discourage people from depending on this interface for production use.
On Wed, Aug 04, 2010 at 09:50:55AM -0500, Anthony Liguori wrote:
On 08/04/2010 09:38 AM, Gleb Natapov wrote:
But even if it wasn't it can potentially create havoc. I think we
currently believe that the northbridge likely never forwards RAM
access to a device so this doesn't fit how hardware
On 08/04/2010 10:01 AM, Gleb Natapov wrote:
Hm, may be. I read seabios code differently, but may be I misread it.
The BIOS Boot Specification spells it all out pretty clearly.
If a ROM needs memory after the init function, it needs to use the
traditional tricks to allocate long term
On Wed, Aug 04, 2010 at 09:57:17AM -0500, Anthony Liguori wrote:
On 08/04/2010 09:51 AM, David S. Ahern wrote:
On 08/03/10 12:43, Avi Kivity wrote:
libguestfs does not depend on an x86 architectural feature.
qemu-system-x86_64 emulates a PC, and PCs don't have -kernel. We should
discourage
On 04.08.2010, at 17:25, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 09:57:17AM -0500, Anthony Liguori wrote:
On 08/04/2010 09:51 AM, David S. Ahern wrote:
On 08/03/10 12:43, Avi Kivity wrote:
libguestfs does not depend on an x86 architectural feature.
qemu-system-x86_64 emulates a PC,
On Wed, Aug 04, 2010 at 05:31:12PM +0200, Alexander Graf wrote:
On 04.08.2010, at 17:25, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 09:57:17AM -0500, Anthony Liguori wrote:
On 08/04/2010 09:51 AM, David S. Ahern wrote:
On 08/03/10 12:43, Avi Kivity wrote:
libguestfs does not
On 04.08.2010, at 17:48, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 05:31:12PM +0200, Alexander Graf wrote:
On 04.08.2010, at 17:25, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 09:57:17AM -0500, Anthony Liguori wrote:
On 08/04/2010 09:51 AM, David S. Ahern wrote:
On 08/03/10 12:43,
On Wed, Aug 04, 2010 at 05:59:40PM +0200, Alexander Graf wrote:
On 04.08.2010, at 17:48, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 05:31:12PM +0200, Alexander Graf wrote:
On 04.08.2010, at 17:25, Gleb Natapov wrote:
On Wed, Aug 04, 2010 at 09:57:17AM -0500, Anthony Liguori
On Mon, Jun 14, 2010, Avi Kivity wrote about Re: [PATCH 13/24] Implement
VMREAD and VMWRITE:
+#ifdef CONFIG_X86_64
+switch (vmcs_field_type(field)) {
+case VMCS_FIELD_TYPE_U64: case VMCS_FIELD_TYPE_ULONG:
+if (!is_long_mode(vcpu)) {
+
On 08/04/2010 04:04 PM, Anthony Liguori wrote:
On 08/04/2010 03:17 AM, Avi Kivity wrote:
For playing games, there are three options:
- existing fwcfg
- fwcfg+dma
- put roms in 4GB-2MB (or whatever we decide the flash size is) and
have the BIOS copy them
Existing fwcfg is the least amount of
On 08/04/2010 04:24 PM, Richard W.M. Jones wrote:
It's boot time, so you can just map it over some existing RAM surely?
Linuxboot.bin can work out where to map it so it won't be in any
memory either being used or the target for the copy.
There's no such thing as boot time from the host's
On 08/04/2010 04:52 PM, Anthony Liguori wrote:
This is not like DMA event if done in chunks and chunks can be pretty
big. The code that dials with copying may temporary unmap some pci
devices to have more space there.
That's a bit complicated because SeaBIOS is managing the PCI devices
On 08/04/2010 05:39 PM, Anthony Liguori wrote:
We could make kernel an awful lot smarter but unless we've got someone
just itching to write 16-bit option rom code, I think our best bet is
to try to leverage a standard bootloader and expose a disk containing
the kernel/initrd.
A problem
On 08/04/2010 07:30 PM, Avi Kivity wrote:
On 08/04/2010 04:52 PM, Anthony Liguori wrote:
This is not like DMA event if done in chunks and chunks can be pretty
big. The code that dials with copying may temporary unmap some pci
devices to have more space there.
That's a bit complicated
On 08/04/2010 07:09 PM, Nadav Har'El wrote:
+ kvm_read_guest_virt(gva,field_value,
+ vmcs_field_size(field_type, vcpu), vcpu, NULL);
Check for exception.
I am not sure what I should really do here... In emulating VMWRITE, we
try to read from memory the
On 08/04/2010 11:30 AM, Avi Kivity wrote:
On 08/04/2010 04:52 PM, Anthony Liguori wrote:
This is not like DMA event if done in chunks and chunks can be pretty
big. The code that dials with copying may temporary unmap some pci
devices to have more space there.
That's a bit complicated
On 08/04/2010 03:53 PM, Anthony Liguori wrote:
So how do we enable support for more than 20 disks? I think a
virtio-scsi is inevitable..
Not only for large numbers of disks, also for JBOD performance. If you
have one queue per disk you'll have low queue depths and high interrupt
rates.
On 08/04/2010 11:36 AM, Avi Kivity wrote:
On 08/04/2010 07:30 PM, Avi Kivity wrote:
On 08/04/2010 04:52 PM, Anthony Liguori wrote:
This is not like DMA event if done in chunks and chunks can be pretty
big. The code that dials with copying may temporary unmap some pci
devices to have more
On 04.08.2010, at 18:36, Avi Kivity wrote:
On 08/04/2010 07:30 PM, Avi Kivity wrote:
On 08/04/2010 04:52 PM, Anthony Liguori wrote:
This is not like DMA event if done in chunks and chunks can be pretty
big. The code that dials with copying may temporary unmap some pci
devices to have more
On 08/04/2010 11:44 AM, Avi Kivity wrote:
On 08/04/2010 03:53 PM, Anthony Liguori wrote:
So how do we enable support for more than 20 disks? I think a
virtio-scsi is inevitable..
Not only for large numbers of disks, also for JBOD performance. If
you have one queue per disk you'll have
On 04.08.2010, at 18:46, Anthony Liguori wrote:
On 08/04/2010 11:44 AM, Avi Kivity wrote:
On 08/04/2010 03:53 PM, Anthony Liguori wrote:
So how do we enable support for more than 20 disks? I think a virtio-scsi
is inevitable..
Not only for large numbers of disks, also for JBOD
On 08/04/2010 07:08 PM, Gleb Natapov wrote:
After applying cache fix nothing definite as far as I remember (I ran it last
time
almost 2 week ago, need to rerun). Code always go through emulator now
and check direction flags to update SI/DI accordingly. Emulator is a big
switch and it calls
On 08/04/2010 11:48 AM, Alexander Graf wrote:
On 04.08.2010, at 18:46, Anthony Liguori wrote:
On 08/04/2010 11:44 AM, Avi Kivity wrote:
On 08/04/2010 03:53 PM, Anthony Liguori wrote:
So how do we enable support for more than 20 disks? I think a virtio-scsi is
inevitable..
On 04.08.2010, at 18:49, Anthony Liguori wrote:
On 08/04/2010 11:48 AM, Alexander Graf wrote:
On 04.08.2010, at 18:46, Anthony Liguori wrote:
On 08/04/2010 11:44 AM, Avi Kivity wrote:
On 08/04/2010 03:53 PM, Anthony Liguori wrote:
So how do we enable support for more
On 08/04/2010 07:44 PM, Anthony Liguori wrote:
The option rom stuff has a number of short comings. Because we hijack
int19, extboot doesn't get to run. That means that if you use -kernel
to load a grub (the Ubuntu guys for their own absurd reasons) then
grub does not see extboot backed
On 08/04/2010 07:45 PM, Alexander Graf wrote:
I see two alternatives out of this mess:
1) Speed up string PIO so we're actually fast again.
Certainly, the best option given that it needs no new interfaces, and
improves the most workloads.
2) Using a different interface (that could also
1 - 100 of 153 matches
Mail list logo
