On Thu, Jun 18, 2009 at 02:46:30PM +0930, Rusty Russell wrote:
> On Mon, 15 Jun 2009 10:24:39 pm Michael S. Tsirkin wrote:
> > On Mon, Jun 15, 2009 at 08:08:18AM -0400, Gregory Haskins wrote:
> > > Hmm. I understand what you are saying conceptually (i.e. the .text
> > > could get yanked before we
Marcelo Tosatti writes:
> On Tue, Jun 16, 2009 at 06:47:45PM +0200, Markus Armbruster wrote:
>> I'm working on make PCI slots configurable in QEMU. While testing the
>> feature for virtio-blk-pci, I ran into a task hang with Fedora kernel
>> 2.6.27.5-117.fc10. Marcelo tested it with a newer ker
On Wed, Jun 17, 2009 at 04:21:19PM -0700, Davide Libenzi wrote:
> The interface is just ugly IMO. You have eventfd_signal() that can sleep,
> or not, depending on the registered ->signal() function implementations.
> This is pretty bad, a lot worse than the theoretical us spent in the
> schedule_
On Wed, 2009-06-17 at 18:24 +0300, Michael Goldish wrote:
> Support 'cache' and 'serial'.
> Both can be controlled directly from the config file, e.g.:
> drive_cache = writeback
>
> or for a specific image 'image1':
> drive_cache_image1 = writeback
>
> or for 'image1' of VM 'vm1':
> drive_cache_i
On Tuesday 16 June 2009 00:29:17 Alex Williamson wrote:
> The PCI code already knows about option ROMs, so we just need to
> mmap some space for it, load it with a copy of the contents, and
> complete the plubming to the generic code.
>
> With this a Linux guest can get access to the ROM contents v
On Mon, 15 Jun 2009 10:24:39 pm Michael S. Tsirkin wrote:
> On Mon, Jun 15, 2009 at 08:08:18AM -0400, Gregory Haskins wrote:
> > Hmm. I understand what you are saying conceptually (i.e. the .text
> > could get yanked before we hit the next line of code, in this case the
> > "return 0"). However,
On Tuesday 16 June 2009 20:05:29 Marcelo Tosatti wrote:
> Do not allow invalid MTRR/PAT values in set_msr_mtrr.
>
> Please review carefully.
>
> Signed-off-by: Marcelo Tosatti
>
Looks fine to me.
Is it necessary to check reserved bit of MSR_MTRRdefType and variable MTRRs as
well? Maybe like this
Hello Everyone
> I went trough the discussion about this patch and I also agree we should
> be implementing this test as a server side test. However I thought it
> would be good having this patch rebased to the new kvm test code just in
> case we need it in the future. This is part of the patch q
On Wed, 17 Jun 2009, Gregory Haskins wrote:
> I am not clear on what you are asking here. So in case this was a
> sincere question on how things work, here is a highlight of the typical
> flow of a packet that ingresses on a physical adapter and routes to KVM
> via vbus.
>
> a) interrupt from et
Hyper-V refuses to run in hypervisor mode when it finds the hypervisor bit
set, because it assumes it's running as a guest.
While the perfect way of not setting the hypervisor would be an option to the
-cpu parameter, this is reasonable sane for now. Let's deal with the -cpu
way when we get to -cp
On 16.06.2009, at 17:13, Avi Kivity wrote:
On 06/16/2009 05:08 PM, Alexander Graf wrote:
Please tell me you tested suspend/resume with/without VMs and cpu
hotunplug/hotplug.
I tested cpu hotplugging. On the last round I tested suspend/
resume, but
this time I couldn't because my machine c
Davide Libenzi wrote:
> On Wed, 17 Jun 2009, Gregory Haskins wrote:
>
>
>> Davide Libenzi wrote:
>>
>>
>>> How much the (possible, but not certain) kernel thread context switch time
>>> weighs in the overall KVM IRQ service time?
>>>
>>>
>> Generally each one is costing me about
On Wed, 17 Jun 2009, Gregory Haskins wrote:
> Davide Libenzi wrote:
>
> > How much the (possible, but not certain) kernel thread context switch time
> > weighs in the overall KVM IRQ service time?
> >
>
> Generally each one is costing me about 7us on average. For something
> like high-speed
Davide Libenzi wrote:
> On Wed, 17 Jun 2009, Gregory Haskins wrote:
>
>
>> Can you elaborate? I currently do not see how I could do the proposed
>> concept inside of irqfd while still using eventfd. Of course, that
>> would be possible if we fork irqfd from eventfd, and perhaps this is
>> wha
This patch adds a command line parameter to expose the gbpages cpuid bit to the
guest if the kvm kernel module supports it.
Signed-off-by: Joerg Roedel
---
qemu-kvm.c |1 +
qemu-kvm.h |1 +
qemu-options.hx |2 ++
target-i386/helper.c |3 +++
vl.c
The cpuid features exposed to the guest are currently not aligned with the bits
returned by the supported_cpuid ioctl. This patch fixes it.
Signed-off-by: Joerg Roedel
---
qemu-kvm-x86.c | 28 +---
1 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/qemu-kv
Fix the bitmask in kvm_setup_cpuid() to a value which represents only the
common bits between cpuid function 0x0001 and 0x8001.
Signed-off-by: Joerg Roedel
---
target-i386/libkvm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/target-i386/libkvm.c b/target-i38
Hi,
this patchset contains two "fixes" to qemu-kvm userspace and the patch to make
gbpages working with qemu-kvm. I am not really sure if this is the right way to
do it or if I missed something. Therefore this patchset is RFC.
Thanks,
Joerg
--
To unsubscribe from this list: send the li
On Wed, 17 Jun 2009, Gregory Haskins wrote:
> Can you elaborate? I currently do not see how I could do the proposed
> concept inside of irqfd while still using eventfd. Of course, that
> would be possible if we fork irqfd from eventfd, and perhaps this is
> what you are proposing. As previousl
Hi Davide,
Davide Libenzi wrote:
> On Tue, 16 Jun 2009, Gregory Haskins wrote:
>
>
>> Davide Libenzi wrote:
>>
>>> On Tue, 16 Jun 2009, Gregory Haskins wrote:
>>>
>>>
>>>
Does this all make sense?
>>> This conversation has been *really* long, and I ha
On Wed, Jun 17, 2009 at 10:53:47AM -0300, Marcelo Tosatti wrote:
>
>
> make_all_cpus_request contains a race condition which can
> trigger false request completed status, as follows:
>
> CPU0 CPU1
>
> if (test_and_set_bit(req,&vcpu->requests))
>
On Tue, 16 Jun 2009, Gregory Haskins wrote:
> Davide Libenzi wrote:
> > On Tue, 16 Jun 2009, Gregory Haskins wrote:
> >
> >
> >> Does this all make sense?
> >>
> >
> > This conversation has been *really* long, and I haven't had time to look
> > at the patch yet. But looking at the amount
Michael S. Tsirkin wrote:
> On Wed, Jun 17, 2009 at 11:02:06AM -0400, Gregory Haskins wrote:
>
>> Michael S. Tsirkin wrote:
>>
>>> On Tue, Jun 16, 2009 at 02:09:38PM -0400, Gregory Haskins wrote:
>>>
>>>
> What do you mean by copy_to_user(other->mm) here? If you are going to
On Wed, Jun 17, 2009 at 11:02:06AM -0400, Gregory Haskins wrote:
> Michael S. Tsirkin wrote:
> > On Tue, Jun 16, 2009 at 02:09:38PM -0400, Gregory Haskins wrote:
> >
> >>> What do you mean by copy_to_user(other->mm) here? If you are going to
> >>> switch
> >>> to another mm, then I think curre
> Subject: Re: Network throughput limits for local VM <-> VM
> communication
>
> On 06/17/2009 11:12 AM, Fischer, Anna wrote:
> >
> > For the tests I run now (with vlan= enabled) I am actually using both
> TCP and UDP, and I see the problem with virtio_net for both protocols.
> What I am wondering
Support 'cache' and 'serial'.
Both can be controlled directly from the config file, e.g.:
drive_cache = writeback
or for a specific image 'image1':
drive_cache_image1 = writeback
or for 'image1' of VM 'vm1':
drive_cache_image1_vm1 = writeback
The cache options are listed in the QEMU documentatio
Michael S. Tsirkin wrote:
> On Tue, Jun 16, 2009 at 02:09:38PM -0400, Gregory Haskins wrote:
>
>>> What do you mean by copy_to_user(other->mm) here? If you are going to
>>> switch
>>> to another mm, then I think current->mm must be valid (I think it's not
>>> enough
>>> that you can sleep). S
On Tue, Jun 16, 2009 at 02:09:38PM -0400, Gregory Haskins wrote:
> > What do you mean by copy_to_user(other->mm) here? If you are going to
> > switch
> > to another mm, then I think current->mm must be valid (I think it's not
> > enough
> > that you can sleep). So preemptible() might not be enou
Mark McLoughlin wrote:
On Wed, 2009-06-17 at 17:44 +0400, Michael Tokarev wrote:
WARNING: at drivers/base/core.c:122 device_release+0x5f/0x70()
Device 'virtio8' does not have a release() function, it is broken and
must be fixed.
This should be fixed in 2.6.29
Yes indeed, 2.6.29 adds/removes
On Wed, Jun 17, 2009 at 10:07:59AM -0300, Marcelo Tosatti wrote:
> On Wed, Jun 17, 2009 at 03:29:05PM +0300, Gleb Natapov wrote:
> > On Tue, Jun 16, 2009 at 11:33:16AM -0300, Marcelo Tosatti wrote:
> > >
> > > On x86 mp_state is initialized by kvm_arch_vcpu_init. Right
> > > now kvm_vcpu_is_bsp re
On Wed, 2009-06-17 at 17:44 +0400, Michael Tokarev wrote:
> WARNING: at drivers/base/core.c:122 device_release+0x5f/0x70()
> Device 'virtio8' does not have a release() function, it is broken and
> must be fixed.
This should be fixed in 2.6.29
Cheers,
Mark.
--
To unsubscribe from this list: send
make_all_cpus_request contains a race condition which can
trigger false request completed status, as follows:
CPU0 CPU1
if (test_and_set_bit(req,&vcpu->requests))
if
(test_and_set_bit(req,&vcpu->re
Handle #UD intercept of the sysexit instruction in 64bit mode returning to
32bit compat mode on an AMD host.
Setup the segment descriptors for CS and SS and the EIP/ESP registers
according to the manual.
Signed-off-by: Christoph Egger
Signed-off-by: Amit Shah
Signed-off-by: Andre Przywara
---
Handle #UD intercept of the syscall instruction in 32bit compat mode on
an Intel host.
Setup the segment descriptors for CS and SS and the EIP/ESP registers
according to the manual. Save the RIP and EFLAGS to the correct registers.
Signed-off-by: Christoph Egger
Signed-off-by: Andre Przywara
---
Handle #UD intercept of the sysenter instruction in 32bit compat mode on
an AMD host.
Setup the segment descriptors for CS and SS and the EIP/ESP registers
according to the manual.
Signed-off-by: Christoph Egger
Signed-off-by: Amit Shah
Signed-off-by: Andre Przywara
---
arch/x86/kvm/x86_emulat
Add the flags needed for syscall, sysenter and sysexit to the opcode table.
Catch (but for now ignore) the opcodes in the emulation switch/case.
Signed-off-by: Andre Przywara
Signed-off-by: Amit Shah
Signed-off-by: Christoph Egger
---
arch/x86/kvm/x86_emulate.c | 17 +++--
1 file
Signed-off-by: Christoph Egger
Signed-off-by: Amit Shah
Signed-off-by: Andre Przywara
---
arch/x86/kvm/x86_emulate.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86_emulate.c b/arch/x86/kvm/x86_emulate.c
index 22c765d..e387c83 100644
--- a/arch/x86/kv
Add the opcodes for syscall, sysenter and sysexit to the list of instructions
handled by the undefined opcode handler.
Signed-off-by: Christoph Egger
Signed-off-by: Amit Shah
Signed-off-by: Andre Przywara
---
arch/x86/kvm/x86.c | 33 ++---
1 files changed, 26 inse
sysenter/sysexit are not supported on AMD's 32bit compat mode, whereas
syscall is not supported on Intel's 32bit compat mode. To allow cross
vendor migration we emulate the missing instructions by setting up the
processor state accordingly.
The sysenter code was originally sketched by Amit Shah, it
I tried drive hot add/remove today.
And immediately had a few.. issues.
qemu-kvm-0.10.5.
First of all, there are several "definitions"
of drive_add and several others in `help'
monitor command output:
This one appears to be real:
drive_add pci_addr=[[:]:]
[file=file][,if=type][,bus=n]
[,unit=m]
On 06/17/2009 03:22 PM, Marcelo Tosatti wrote:
Return EOPNOTSUPP for KVM_TRACE_ENABLE/PAUSE/DISABLE ioctls.
I dropped this patch, breaks the powerpc build. I guess it should be
simple to convert powerpc?
--
Do not meddle in the internals of kernels, for they are subtle and quick to
pa
On Wed, Jun 17, 2009 at 03:29:05PM +0300, Gleb Natapov wrote:
> On Tue, Jun 16, 2009 at 11:33:16AM -0300, Marcelo Tosatti wrote:
> >
> > On x86 mp_state is initialized by kvm_arch_vcpu_init. Right
> > now kvm_vcpu_is_bsp returns false because kvm->bsp_vcpu has
> > not been initialized, so vcpu_id
On 06/17/2009 03:22 PM, Marcelo Tosatti wrote:
Applied, thanks.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
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 Tue, Jun 16, 2009 at 11:33:16AM -0300, Marcelo Tosatti wrote:
>
> On x86 mp_state is initialized by kvm_arch_vcpu_init. Right
> now kvm_vcpu_is_bsp returns false because kvm->bsp_vcpu has
> not been initialized, so vcpu_id == 0 ends up with mp_state ==
> KVM_MP_STATE_UNINITIALIZED.
>
> Gleb do
This allows use of the powerful ftrace infrastructure.
See Documentation/trace/ for usage information.
Signed-off-by: Marcelo Tosatti
Index: kvm/arch/x86/kvm/lapic.c
===
--- kvm.orig/arch/x86/kvm/lapic.c
+++ kvm/arch/x86/kvm/lapic.
Return EOPNOTSUPP for KVM_TRACE_ENABLE/PAUSE/DISABLE ioctls.
Signed-off-by: Marcelo Tosatti
Index: kvm/virt/kvm/kvm_main.c
===
--- kvm.orig/virt/kvm/kvm_main.c
+++ kvm/virt/kvm/kvm_main.c
@@ -2367,7 +2367,7 @@ static long kvm_dev_i
--
--
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
On 06/17/2009 11:12 AM, Fischer, Anna wrote:
For the tests I run now (with vlan= enabled) I am actually using both TCP and
UDP, and I see the problem with virtio_net for both protocols. What I am
wondering about though is that I do not seem to have any problems if I
communicate directly betwe
Avi Kivity wrote:
> >If management apps need to hard-code which slots are available on
> >different targets and different qemu versions, or restrictions on which
> >devices can use which slots, or knowledge that some devices can be
> >multi-function, or ... anything like that is just lame.
> >
>
On 06/17/2009 01:13 AM, Marcelo Tosatti wrote:
Return EOPNOTSUPP for KVM_TRACE_ENABLE/PAUSE/DISABLE ioctls.
The first feature we remove, we don't have a KVM_CAP for.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
To unsubscribe from this list: s
On Tue, Jun 16, 2009 at 03:40:13PM -0500, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> Change much of hw/pci to use symbolic constants and a table-driven
>> design: add a mask table with writable bits set and readonly bits unset.
>> Detect change by comparing original and new registers.
>>
On 06/17/2009 01:13 AM, Marcelo Tosatti wrote:
This allows use of the powerful ftrace infrastructure.
See Documentation/trace/ for usage information.
This only applied with -C0, so I'm worried something's broken. Please
regenerate.
--
Do not meddle in the internals of kernels, for the
Avi Kivity wrote:
> On 06/16/2009 09:32 PM, Jamie Lokier wrote:
> >Avi Kivity wrote:
> >
> >>Another issue is enumeration. Guests will present their devices in the
> >>order they find them on the pci bus (of course enumeration is guest
> >>specific). So if I have 2 virtio controllers the only
Avi Kivity wrote:
On 06/17/2009 11:38 AM, Michael Tokarev wrote:
After seeing words from Avi about that smp guests
are ok now, I descided to try. And immediately
got a few questions.
Running on a Phenom 9750 machine (PhenomI), AMD780G
chipset. Host is 2.6.29 x86-64, qemu-kvm 0.10.5,
guests ar
On 06/17/2009 12:18 PM, Mark McLoughlin wrote:
On Wed, 2009-06-17 at 12:03 +0300, Avi Kivity wrote:
On 06/17/2009 11:33 AM, Mark McLoughlin wrote:
I particularly don't like the idea of arcane machine-dependent slot
allocation knowledge living in libvirt, because it needs to be in Qemu
On Wed, 2009-06-17 at 12:03 +0300, Avi Kivity wrote:
> On 06/17/2009 11:33 AM, Mark McLoughlin wrote:
> >> I particularly don't like the idea of arcane machine-dependent slot
> >> allocation knowledge living in libvirt, because it needs to be in Qemu
> >> anyway for non-libvirt users. No point in
On 06/17/2009 11:38 AM, Michael Tokarev wrote:
After seeing words from Avi about that smp guests
are ok now, I descided to try. And immediately
got a few questions.
Running on a Phenom 9750 machine (PhenomI), AMD780G
chipset. Host is 2.6.29 x86-64, qemu-kvm 0.10.5,
guests are linux with kvm pa
On 06/17/2009 11:33 AM, Mark McLoughlin wrote:
I particularly don't like the idea of arcane machine-dependent slot
allocation knowledge living in libvirt, because it needs to be in Qemu
anyway for non-libvirt users. No point in having two implementations
of something tricky and likely to have ma
After seeing words from Avi about that smp guests
are ok now, I descided to try. And immediately
got a few questions.
Running on a Phenom 9750 machine (PhenomI), AMD780G
chipset. Host is 2.6.29 x86-64, qemu-kvm 0.10.5,
guests are linux with kvm paravirt bits enabled, also
dynticks (on both host
On Tue, 2009-06-16 at 19:44 +0100, Jamie Lokier wrote:
> Mark McLoughlin wrote:
> > > Worst case we hardcode those numbers (gasp, faint).
> >
> > Maybe we can just add the open slots to the -help output. That'd be nice
> > and clean.
I was being sarcastic - libvirt currently must parse qemu -help
> Subject: Re: Network throughput limits for local VM <-> VM
> communication
>
> On 06/17/2009 10:36 AM, Fischer, Anna wrote:
> >
> > /usr/bin/qemu-system-x86_64 -m 1024 -smp 2 -name FC10-2 -uuid
> b811b278-fae2-a3cc-d51d-8f5b078b2477 -boot c -drive
> file=,if=ide,media=cdrom,index=2 -drive
> file
On 06/17/2009 10:36 AM, Fischer, Anna wrote:
/usr/bin/qemu-system-x86_64 -m 1024 -smp 2 -name FC10-2 -uuid
b811b278-fae2-a3cc-d51d-8f5b078b2477 -boot c -drive
file=,if=ide,media=cdrom,index=2 -drive
file=/var/lib/libvirt/images/FC10-2.img,if=virtio,index=0,boot=on -net
nic,macaddr=54:52:00:1
Amit Shah wrote:
Hi Andre,
On (Tue) Jun 16 2009 [15:25:13], Andre Przywara wrote:
sysenter/sysexit are not supported on AMD's 32bit compat mode, whereas
syscall is not supported on Intel's 32bit compat mode. To allow cross
vendor migration we emulate the missing instructions by setting up the
p
> Subject: Re: Network throughput limits for local VM <-> VM
> communication
>
> Fischer, Anna wrote:
> > Not sure I understand. As far as I can see the packets are replicated
> on the tun/tap interface before they actually enter the bridge. So this
> is not about the bridge learning MAC addresses
On 06/16/2009 07:47 PM, Markus Armbruster wrote:
I'm working on make PCI slots configurable in QEMU. While testing the
feature for virtio-blk-pci, I ran into a task hang with Fedora kernel
2.6.27.5-117.fc10. Marcelo tested it with a newer kernel, and will
follow up with details.
Some slots wo
On 06/16/2009 04:25 PM, Andre Przywara wrote:
sysenter/sysexit are not supported on AMD's 32bit compat mode, whereas
syscall is not supported on Intel's 32bit compat mode. To allow cross
vendor migration we emulate the missing instructions by setting up the
processor state accordingly.
The sysent
66 matches
Mail list logo
