On 15.04.2012 11:44, Avi Kivity wrote:
On 04/12/2012 09:32 PM, Gerhard Wiesinger wrote:
Hello,
I'm having problems with recents kernels and qemu-kvm with a DOS VM:
TD286
System: Bad selector: 0007
System: Bad selector: 0D87
System: Bad selector: 001F
System: Bad selector: 0007
GP at 0020 21D4
On 04/15/2012 05:32 PM, Avi Kivity wrote:
On 04/13/2012 05:25 PM, Takuya Yoshikawa wrote:
I forgot to say one important thing -- I might give you wrong impression.
I am perfectly fine with your lock-less work. It is really nice!
The reason I say much about O(1) is that O(1) and rmap based
On 04/16/2012 11:49 PM, Takuya Yoshikawa wrote:
Although O(1) is actually O(1) for GET_DIRTY_LOG thread, it adds some
overheads to page fault handling. We may need to hold mmu_lock for properly
handling O(1)'s write protection and ~500 write protections will not be so
cheap. And there is
On Tue, Apr 17, 2012 at 08:04:16AM +0200, Gerhard Wiesinger wrote:
On 15.04.2012 11:44, Avi Kivity wrote:
On 04/12/2012 09:32 PM, Gerhard Wiesinger wrote:
Hello,
I'm having problems with recents kernels and qemu-kvm with a DOS VM:
TD286
System: Bad selector: 0007
System: Bad selector:
On 04/12/2012 05:45 AM, Marcelo Tosatti wrote:
On Fri, Mar 23, 2012 at 01:37:26PM +0530, Raghavendra K T wrote:
From: Raghavendra K Traghavendra...@linux.vnet.ibm.com
[...]
Unless there is a reason to use an MSR, should use a normal ioctl
such as KVM_{GET,SET}_MP_STATE.
I agree with
On 04/12/2012 05:59 AM, Marcelo Tosatti wrote:
On Wed, Apr 11, 2012 at 09:06:29PM -0300, Marcelo Tosatti wrote:
On Fri, Mar 23, 2012 at 01:37:04PM +0530, Raghavendra K T wrote:
From: Srivatsa Vaddagiriva...@linux.vnet.ibm.com
[...]
barrier();
Is it always OK to erase the
On 04/17/2012 09:57 AM, Gleb Natapov wrote:
Status is as follows:
1.) Kernel 3.4.x DIDN'T fix the problem
2.) Reverting f1c1da2bde712812a3e0f9a7a7ebe7a916a4b5f4 FIXED the problem.
So the bug is still in 3.2., 3.3, 3.4rc present and a possible fix
doesn't work. Should be fixed in
On 04/17/2012 06:55 AM, Xiao Guangrong wrote:
On 04/16/2012 07:47 PM, Avi Kivity wrote:
On 04/16/2012 01:20 PM, Xiao Guangrong wrote:
It is used to avoid the unnecessary overload
It's overloading me :(
Sorry.
The trick is to send those in separate patchset so the
On 04/11/2012 04:39 AM, zhangyanfei wrote:
This patch set exports offsets of VMCS fields as note information for
kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
runtime state of guest machine image, such as registers, in host
machine's crash dump as VMCS format. The problem
On 04/17/2012 02:05 AM, Benjamin Herrenschmidt wrote:
On Mon, 2012-04-16 at 15:53 +0300, Avi Kivity wrote:
kvm.git next is exposed to linux-next, where they get tested quite a
lot. Granted it's mostly build testing, and people are unlikely to
test
kvm there, but they will test the
On 04/17/2012 09:26 AM, Xiao Guangrong wrote:
On 04/16/2012 11:49 PM, Takuya Yoshikawa wrote:
Although O(1) is actually O(1) for GET_DIRTY_LOG thread, it adds some
overheads to page fault handling. We may need to hold mmu_lock for properly
handling O(1)'s write protection and ~500 write
On 12.04.2012 11:42, Hans-Kristian Bakke wrote:
Hi
For some reason I am not able to get good network performance using
virtio/vhost-net on Debian KVM host (perhaps also valid for Ubuntu
hosts then).
The issue has been identified, after Hans-Kristian gave me access
to his machine and I did
On Mon, Apr 16, 2012 at 9:51 AM, Ron Edison r...@idthq.com wrote:
I would be very interested in how to ensure the guests are sending flushes.
I'm unfamiliar with the example you gave, where is that configured?
mount -o barrier=1 /dev/sda /mnt is a mount option for ext3 and ext4
file systems.
On Mon, Apr 16, 2012 at 09:56:02PM +0300, Michael S. Tsirkin wrote:
On Mon, Apr 16, 2012 at 08:37:37PM +0300, Gleb Natapov wrote:
On Mon, Apr 16, 2012 at 08:24:16PM +0300, Michael S. Tsirkin wrote:
On Mon, Apr 16, 2012 at 06:10:11PM +0300, Gleb Natapov wrote:
lapic changes should be
From: Marcelo Tosatti mtosa...@redhat.com
Subject: Re: EuroSec'12 Presentation (ASLR reduces effect of KSM)
Date: Mon, 16 Apr 2012 21:29:31 -0300
On Mon, Apr 16, 2012 at 03:52:10PM +0900, Kuniyasu Suzaki wrote:
Marcelo,
From: Marcelo Tosatti mtosa...@redhat.com
Subject: Re:
On Mon, Apr 16, 2012 at 10:01:29PM +0300, Michael S. Tsirkin wrote:
On Mon, Apr 16, 2012 at 08:51:16PM +0300, Gleb Natapov wrote:
Only when eoi is pending. This is rare.
This is exactly while guest handles an interrupt.
It's not all that rare at all: e.g. device
drivers cause an
On 04/17/2012 05:55 AM, Bharat Bhushan wrote:
Time for which the hrtimer is started for decrementer emulation is calculated using
tb_ticks_per_usec. While hrtimer uses the clockevent for DEC reprogramming (if
needed) and which calculate timebase ticks using the multiplier and shifter mechanism
On 04/16/2012 01:08 PM, Gleb Natapov wrote:
}
+
+ if (kvm_para_has_feature(KVM_FEATURE_EOI)) {
+ kvm_guest_native_apic_write = apic-write;
+ apic-write = kvm_guest_apic_write;
+ wrmsrl(MSR_KVM_EOI_EN, __pa(__get_cpu_var(apic_eoi)));
+ }
On 04/16/2012 03:18 PM, Michael S. Tsirkin wrote:
On Mon, Apr 16, 2012 at 02:24:46PM +0300, Gleb Natapov wrote:
On Mon, Apr 16, 2012 at 02:09:20PM +0300, Michael S. Tsirkin wrote:
Thanks very much for the review. I'll address the comments.
Some questions on your comments below.
On
On Mon, Apr 16, 2012 at 06:33:26PM +0200, Jan Kiszka wrote:
On 2010-06-16 23:11, Chris Lalancette wrote:
We really want to kvm_set_irq during the hrtimer callback,
but that is risky because that is during interrupt context.
Instead, offload the work to a workqueue, which is a bit safer
On 04/17/2012 09:20 AM, Avi Kivity wrote:
On 04/17/2012 02:05 AM, Benjamin Herrenschmidt wrote:
On Mon, 2012-04-16 at 15:53 +0300, Avi Kivity wrote:
kvm.git next is exposed to linux-next, where they get tested quite a
lot. Granted it's mostly build testing, and people are unlikely to
test
kvm
On Mon, Apr 16, 2012 at 07:44:39AM -0700, Chegu Vinod wrote:
On 4/16/2012 5:18 AM, Gleb Natapov wrote:
On Thu, Apr 12, 2012 at 02:21:06PM -0400, Rik van Riel wrote:
On 04/11/2012 01:21 PM, Chegu Vinod wrote:
Hello,
While running an AIM7 (workfile.high_systime) in a single 40-way (or a
On 04/17/2012 12:31 PM, Gleb Natapov wrote:
On Mon, Apr 16, 2012 at 06:33:26PM +0200, Jan Kiszka wrote:
On 2010-06-16 23:11, Chris Lalancette wrote:
We really want to kvm_set_irq during the hrtimer callback,
but that is risky because that is during interrupt context.
Instead, offload
On 04/17/2012 12:34 PM, Alexander Graf wrote:
tree but his tree is in linux-next as well. There's no reason not to do
that.
That way, his next branch gets linux-next coverage whether it's in my
tree or not, and I pull when I put the final powerpc-next together,
which gives me a chance to do
On Tue, Apr 17, 2012 at 01:23:52PM +0300, Avi Kivity wrote:
On 04/17/2012 12:31 PM, Gleb Natapov wrote:
On Mon, Apr 16, 2012 at 06:33:26PM +0200, Jan Kiszka wrote:
On 2010-06-16 23:11, Chris Lalancette wrote:
We really want to kvm_set_irq during the hrtimer callback,
but that is
On 04/16/2012 09:26 PM, Jan Kiszka wrote:
We can't run PIT IRQ injection work in the interrupt context of the host
timer. This would allow the user to influence the handler complexity by
asking for a broadcast to a large number of VCPUs. Therefore, this work
was pushed into workqueue context
On 04/17/2012 01:26 PM, Gleb Natapov wrote:
It isn't, since you need to send an IPI.
That is exactly what I forget whether you can send IPI from there :)
Anyway this is another reason.
Actually I was wrong. You can't smp_call_function_single() from irq
context (deadlocks if two vcpus do
On Tue, Apr 17, 2012 at 01:29:04PM +0300, Avi Kivity wrote:
On 04/17/2012 01:26 PM, Gleb Natapov wrote:
It isn't, since you need to send an IPI.
That is exactly what I forget whether you can send IPI from there :)
Anyway this is another reason.
Actually I was wrong. You can't
On 04/17/2012 01:31 PM, Gleb Natapov wrote:
On Tue, Apr 17, 2012 at 01:29:04PM +0300, Avi Kivity wrote:
On 04/17/2012 01:26 PM, Gleb Natapov wrote:
It isn't, since you need to send an IPI.
That is exactly what I forget whether you can send IPI from there :)
Anyway this is another
On 04/17/2012 01:42 PM, Avi Kivity wrote:
On 04/17/2012 01:31 PM, Gleb Natapov wrote:
On Tue, Apr 17, 2012 at 01:29:04PM +0300, Avi Kivity wrote:
On 04/17/2012 01:26 PM, Gleb Natapov wrote:
It isn't, since you need to send an IPI.
That is exactly what I forget whether you can
于 2012年04月17日 15:44, Avi Kivity 写道:
On 04/11/2012 04:39 AM, zhangyanfei wrote:
This patch set exports offsets of VMCS fields as note information for
kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
runtime state of guest machine image, such as registers, in host
machine's
On 04/17/2012 01:51 PM, zhangyanfei wrote:
于 2012年04月17日 15:44, Avi Kivity 写道:
On 04/11/2012 04:39 AM, zhangyanfei wrote:
This patch set exports offsets of VMCS fields as note information for
kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
runtime state of guest machine
On Tue, Apr 17, 2012 at 01:42:31PM +0300, Avi Kivity wrote:
On 04/17/2012 01:31 PM, Gleb Natapov wrote:
On Tue, Apr 17, 2012 at 01:29:04PM +0300, Avi Kivity wrote:
On 04/17/2012 01:26 PM, Gleb Natapov wrote:
It isn't, since you need to send an IPI.
That is exactly what I
On 2012-04-17 12:27, Avi Kivity wrote:
On 04/16/2012 09:26 PM, Jan Kiszka wrote:
We can't run PIT IRQ injection work in the interrupt context of the host
timer. This would allow the user to influence the handler complexity by
asking for a broadcast to a large number of VCPUs. Therefore, this
On 2012-04-16 21:53, Michael S. Tsirkin wrote:
Real command register is under kernel control:
it includes bits for triggering SERR, marking
BARs as invalid and such which are under host
kernel control. Don't touch any except bus master
which is ok to put under guest control and intx
mask
On 2012-04-17 13:24, Jan Kiszka wrote:
On 2012-04-16 21:53, Michael S. Tsirkin wrote:
Real command register is under kernel control:
it includes bits for triggering SERR, marking
BARs as invalid and such which are under host
kernel control. Don't touch any except bus master
which is ok to
On 04/17/2012 02:18 PM, Jan Kiszka wrote:
On 2012-04-17 12:27, Avi Kivity wrote:
On 04/16/2012 09:26 PM, Jan Kiszka wrote:
We can't run PIT IRQ injection work in the interrupt context of the host
timer. This would allow the user to influence the handler complexity by
asking for a
On 04/17/2012 02:05 PM, Gleb Natapov wrote:
On Tue, Apr 17, 2012 at 01:42:31PM +0300, Avi Kivity wrote:
On 04/17/2012 01:31 PM, Gleb Natapov wrote:
On Tue, Apr 17, 2012 at 01:29:04PM +0300, Avi Kivity wrote:
On 04/17/2012 01:26 PM, Gleb Natapov wrote:
It isn't, since you need to
On Tue, Apr 17, 2012 at 03:00:10PM +0300, Avi Kivity wrote:
On 04/17/2012 02:05 PM, Gleb Natapov wrote:
On Tue, Apr 17, 2012 at 01:42:31PM +0300, Avi Kivity wrote:
On 04/17/2012 01:31 PM, Gleb Natapov wrote:
On Tue, Apr 17, 2012 at 01:29:04PM +0300, Avi Kivity wrote:
On 04/17/2012
On 04/17/2012 03:03 PM, Gleb Natapov wrote:
KVM_MAX_VCPUS.
Ah, so you are worried about malicious guest configuring pit to
broadcast to all its vcpus.
Yes - it can introduce huge amounts of latency this way which is exactly
what Jan is trying to prevent.
Though I'm not sure
Real command register is under kernel control:
it includes bits for triggering SERR, marking
BARs as invalid and such which are all under host
kernel control.
While there's no known bug this triggers - since qemu does its
best to make guest state match device state -
it seems safer to avoid
On 04/17/2012 03:41 PM, Avi Kivity wrote:
On 04/17/2012 06:55 AM, Xiao Guangrong wrote:
On 04/16/2012 07:47 PM, Avi Kivity wrote:
On 04/16/2012 01:20 PM, Xiao Guangrong wrote:
It is used to avoid the unnecessary overload
It's overloading me :(
Sorry.
The trick is to send those in
At 04/17/2012 06:59 PM, Avi Kivity Wrote:
On 04/17/2012 01:51 PM, zhangyanfei wrote:
于 2012年04月17日 15:44, Avi Kivity 写道:
On 04/11/2012 04:39 AM, zhangyanfei wrote:
This patch set exports offsets of VMCS fields as note information for
kdump. We call it VMCSINFO. The purpose of VMCSINFO is to
On Tue, 17 Apr 2012 10:51:40 +0300
Avi Kivity a...@redhat.com wrote:
That's true with the write protect everything approach we use now. But
it's not true with range-based write protection, where you issue
GET_DIRTY_LOG on a range of pages and only need to re-write-protect them.
(the
On 04/17/2012 03:37 PM, Takuya Yoshikawa wrote:
On Tue, 17 Apr 2012 10:51:40 +0300
Avi Kivity a...@redhat.com wrote:
That's true with the write protect everything approach we use now. But
it's not true with range-based write protection, where you issue
GET_DIRTY_LOG on a range of pages
On Tue, Apr 17, 2012 at 01:24:24PM +0200, Jan Kiszka wrote:
+/* Pass bus master writes to device. */
+pci_dev-emulate_config_write[PCI_COMMAND] = ~PCI_COMMAND_MASTER;
+pci_dev-emulate_config_write[PCI_COMMAND + 1] =
~(PCI_COMMAND_INTX_DISABLE 8);
Comment doesn't fully
On 04/17/2012 02:25 PM, Wen Congyang wrote:
For scenario 2, we also want the guest's registers values to be dumped into
qemu process's core file when qemu process crashes. This is the task of
TODO-list 2.
Why? If qemu crashed it is because of an internal qemu fault. If any
On 4/17/2012 2:49 AM, Gleb Natapov wrote:
On Mon, Apr 16, 2012 at 07:44:39AM -0700, Chegu Vinod wrote:
On 4/16/2012 5:18 AM, Gleb Natapov wrote:
On Thu, Apr 12, 2012 at 02:21:06PM -0400, Rik van Riel wrote:
On 04/11/2012 01:21 PM, Chegu Vinod wrote:
Hello,
While running an AIM7
Juan Quintela quint...@redhat.com wrote:
Hi
Please send in any agenda items you are interested in covering.
As there are no topics, we cancel today call.
Happy hacking, Juan.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
On Mon, 16 Apr 2012 11:36:25 +0800
Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote:
I tested it with kernbench, no regression is found.
Because kernbench is not at all good test for this.
It is not a problem since the iter and spte should be in the cache.
I have checked dirty-log-perf
On Tue, 17 Apr 2012 15:41:39 +0300
Avi Kivity a...@redhat.com wrote:
Since there are many known algorithms to predict hot memory pages,
the userspace will be able to tune the frequency of GET_DIRTY_LOG for such
parts not to get too many faults repeatedly, if we can restrict the range
of
On 04/17/2012 05:54 PM, Takuya Yoshikawa wrote:
On Tue, 17 Apr 2012 15:41:39 +0300
Avi Kivity a...@redhat.com wrote:
Since there are many known algorithms to predict hot memory pages,
the userspace will be able to tune the frequency of GET_DIRTY_LOG for such
parts not to get too many
On 2012-04-17 14:06, Avi Kivity wrote:
On 04/17/2012 03:03 PM, Gleb Natapov wrote:
KVM_MAX_VCPUS.
Ah, so you are worried about malicious guest configuring pit to
broadcast to all its vcpus.
Yes - it can introduce huge amounts of latency this way which is exactly
what Jan is trying to
On 04/17/2012 07:15 PM, Jan Kiszka wrote:
On 2012-04-17 14:06, Avi Kivity wrote:
On 04/17/2012 03:03 PM, Gleb Natapov wrote:
KVM_MAX_VCPUS.
Ah, so you are worried about malicious guest configuring pit to
broadcast to all its vcpus.
Yes - it can introduce huge amounts of latency
On 04/17/2012 02:44 AM, Avi Kivity wrote:
On 04/11/2012 04:39 AM, zhangyanfei wrote:
This patch set exports offsets of VMCS fields as note information for
kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
runtime state of guest machine image, such as registers, in host
On Tue, 2012-04-17 at 15:10 +0300, Michael S. Tsirkin wrote:
Real command register is under kernel control:
it includes bits for triggering SERR, marking
BARs as invalid and such which are all under host
kernel control.
While there's no known bug this triggers - since qemu does its
best to
On 2012-04-17 14:10, Michael S. Tsirkin wrote:
Real command register is under kernel control:
it includes bits for triggering SERR, marking
BARs as invalid and such which are all under host
kernel control.
While there's no known bug this triggers - since qemu does its
best to make guest
Greetings everybody,
Can anybody please point me to code/documentation regarding the
following questions I have:
- What does it actually mean using -smp N option, in terms of CPU
sharing between the host and the guest?
- How are guest CPUs mapped to host CPUs (if at all)?
- Is it possible to
qemu-kvm-1.0.1 is now available. This release is based on the upstream
qemu 1.0.1, plus kvm-specific enhancements. Please see the
original QEMU 1.0.1 release announcement [1] for details.
This release can be used with the kvm kernel modules provided by your
distribution kernel, or by the modules
As pointed out by Jason Baron, when assigning a device to a guest
we first set the iommu domain pointer, which enables mapping
and unmapping of memory slots to the iommu. This leaves a window
where this path is enabled, but we haven't synchronized the iommu
mappings to the existing memory slots.
On 04/17/2012 10:47 PM, Takuya Yoshikawa wrote:
On Mon, 16 Apr 2012 11:36:25 +0800
Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote:
I tested it with kernbench, no regression is found.
Because kernbench is not at all good test for this.
It is not a problem since the iter and spte
On 04/18/2012 09:47 AM, Marcelo Tosatti wrote:
On Fri, Apr 13, 2012 at 06:16:33PM +0800, Xiao Guangrong wrote:
If the the present bit of page fault error code is set, it indicates
the shadow page is populated on all levels, it means what we do is
only modify the access bit which can be done
Negative also here:
Don't see anything on screen on startup...
From log, latest qemu-kvm git version:
Running option rom at c180:3d4e
Running option rom at c180:3da2
Running option rom at c180:3df6
Running option rom at c580:0003
qemu-system-x86_64: /root/download/qemu/git/qemu-kvm/exec.c:2641:
On 04/16/2012 11:49 PM, Takuya Yoshikawa wrote:
Although O(1) is actually O(1) for GET_DIRTY_LOG thread, it adds some
overheads to page fault handling. We may need to hold mmu_lock for properly
handling O(1)'s write protection and ~500 write protections will not be so
cheap. And there is
On 04/17/2012 09:26 AM, Xiao Guangrong wrote:
On 04/16/2012 11:49 PM, Takuya Yoshikawa wrote:
Although O(1) is actually O(1) for GET_DIRTY_LOG thread, it adds some
overheads to page fault handling. We may need to hold mmu_lock for properly
handling O(1)'s write protection and ~500 write
On 04/17/2012 05:55 AM, Bharat Bhushan wrote:
Time for which the hrtimer is started for decrementer emulation is calculated using
tb_ticks_per_usec. While hrtimer uses the clockevent for DEC reprogramming (if
needed) and which calculate timebase ticks using the multiplier and shifter mechanism
On Tue, 17 Apr 2012 10:51:40 +0300
Avi Kivity a...@redhat.com wrote:
That's true with the write protect everything approach we use now. But
it's not true with range-based write protection, where you issue
GET_DIRTY_LOG on a range of pages and only need to re-write-protect them.
(the
On 04/17/2012 03:37 PM, Takuya Yoshikawa wrote:
On Tue, 17 Apr 2012 10:51:40 +0300
Avi Kivity a...@redhat.com wrote:
That's true with the write protect everything approach we use now. But
it's not true with range-based write protection, where you issue
GET_DIRTY_LOG on a range of pages
On Tue, 17 Apr 2012 15:41:39 +0300
Avi Kivity a...@redhat.com wrote:
Since there are many known algorithms to predict hot memory pages,
the userspace will be able to tune the frequency of GET_DIRTY_LOG for such
parts not to get too many faults repeatedly, if we can restrict the range
of
On 04/17/2012 05:54 PM, Takuya Yoshikawa wrote:
On Tue, 17 Apr 2012 15:41:39 +0300
Avi Kivity a...@redhat.com wrote:
Since there are many known algorithms to predict hot memory pages,
the userspace will be able to tune the frequency of GET_DIRTY_LOG for such
parts not to get too many
70 matches
Mail list logo
