On Mon, Aug 27, 2012 at 01:34:36PM -0600, David Ahern wrote:
On 8/27/12 9:53 AM, Andrew Jones wrote:
On Mon, Aug 27, 2012 at 05:51:46PM +0800, Dong Hao wrote:
snip
+struct event_stats {
+ u64 count;
+ u64 time;
+
+ /* used to calculate stddev. */
+ double mean;
+ double M2;
On 27.08.2012 22:56, Blue Swirl wrote:
[]
+static uint32_t slow_bar_readb(void *opaque, target_phys_addr_t addr)
+{
+AssignedDevRegion *d = opaque;
+uint8_t *in = d-u.r_virtbase + addr;
Don't perform arithmetic with void pointers.
There are a few places in common qemu code which
On 28.08.2012 00:11, Henry Cejtin wrote:
I'm completely confused about access to /dev/kvm. In particular, it
looks like it is too open to access, but in a way that I don't
understand.
On my machine, /dev/kvm is owned by root.root and mode 660. Here is the
output of ls:
Hi Alex,
In my susyem I have following devices:
I tried assigning a following PCI devices:
00:03.0 Communication controller: Intel Corporation 4 Series Chipset HECI
Controller (rev 03)
00:03.2 IDE interface: Intel Corporation 4 Series Chipset PT IDER Controller
(rev 03)
00:03.3 Serial
On Mon, 27 Aug 2012 17:25:42 -0300
Marcelo Tosatti mtosa...@redhat.com wrote:
On Fri, Aug 24, 2012 at 06:15:49PM +0900, Takuya Yoshikawa wrote:
Although returning -1 should be likely according to the likely(),
the ASSERT in apic_find_highest_irr() will be triggered in such a case.
It seems
Hi all,
this series adds multiqueue support to the virtio-scsi driver, based
on Jason Wang's work on virtio-net. It uses a simple queue steering
algorithm that expects one queue per CPU. LUNs in the same target always
use the same queue (so that commands are not reordered); queue switching
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU,
From: Jason Wang jasow...@redhat.com
Instead of storing the queue index in transport-specific virtio structs,
this patch moves them to vring_virtqueue and introduces an helper to get
the value. This lets drivers simplify their management and tracing of
virtqueues.
Signed-off-by: Jason Wang
From: Jason Wang jasow...@redhat.com
Sometimes, virtio device need to configure irq affinity hint to maximize the
performance. Instead of just exposing the irq of a virtqueue, this patch
introduce an API to set the affinity for a virtqueue.
The api is best-effort, the affinity hint may not be
We will place the request virtqueues in the flexible array member.
Refining the virtqueue API would let us drop the sglist copy, at
which point the pointer-to-array-of-pointers can become a simple
pointer-to-array. It would both simplify the allocation and remove a
dereference in several hot
This will be needed soon in order to retrieve the per-target
struct.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
drivers/scsi/virtio_scsi.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
James,
here are three important bugfixes for virtio-scsi. All three have been
on the list for a while, I'm grouping them in this post to ease your
processing.
Two of them are also marked for stable branches.
Paolo
Paolo Bonzini (1):
virtio-scsi: fix LUNs greater than 255
Richard W.M. Jones
From: Richard W.M. Jones rjo...@redhat.com
The sg struct for events is used without being initialized. This
triggers a BUG_ON if CONFIG_DEBUG_SG is defined.
This was reported at https://bugzilla.redhat.com/show_bug.cgi?id=847548.
Signed-off-by: Richard W.M. Jones rjo...@redhat.com
From: Benjamin Herrenschmidt b...@kernel.crashing.org
When making a vcpu non-runnable we incorrectly changed the
thread IDs of all other threads on the core, just remove that
code.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Signed-off-by: Paul Mackerras pau...@samba.org
---
Subsequent patches implementing in-kernel XICS emulation will make it
possible for IPIs to arrive at secondary threads at arbitrary times.
This fixes some races in how we start the secondary threads, which
if not fixed could lead to occasional crashes of the host kernel.
This makes sure that (a)
When a Book3S HV KVM guest is running, we need the host to be in
single-thread mode, that is, all of the cores (or at least all of
the cores where the KVM guest could run) to be running only one
active hardware thread. This is because of the hardware restriction
in POWER processors that all of
Currently the Book3S HV code implements a policy on multi-threaded
processors (i.e. POWER7) that requires all of the active vcpus in a
virtual core to be ready to run before we run the virtual core.
However, that causes problems on reset, because reset stops all vcpus
except vcpu 0, and can also
The generic KVM code uses SRCU (sleeping RCU) to protect accesses
to the memslots data structures against updates due to userspace
adding, modifying or removing memory slots. We need to do that too,
both to avoid accessing stale copies of the memslots and to avoid
lockdep warnings. This
This set of 12 patches contains various fixes collected during the
process of getting reboot of Book3S HV guests to work correctly, plus
some needed for Ben H's forthcoming series to implement in-kernel XICS
(interrupt controller) emulation, plus two patches around handling
memslots properly.
In the case where the host kernel is using a 64kB base page size and
the guest uses a 4k HPTE (hashed page table entry) to map an emulated
MMIO device, we were calculating the guest physical address wrongly.
We were calculating a gfn as the guest physical address shifted right
16 bits (PAGE_SHIFT)
If a thread in a virtual core becomes runnable while other threads
in the same virtual core are already running in the guest, it is
possible for the latecomer to join the others on the core without
first pulling them all out of the guest. Currently this only happens
rarely, when a vcpu is first
Currently the code that accounts stolen time tends to overestimate the
stolen time, and will sometimes report more stolen time in a DTL
(dispatch trace log) entry than has elapsed since the last DTL entry.
This can cause guests to underflow the user or system time measured
for some tasks, leading
From: Benjamin Herrenschmidt b...@kernel.crashing.org
This patch removes the powerpc generic updates of vcpu-cpu in
load and put, and moves them to the various backends.
The reason is that HV KVM does its own sauce with that field
and the generic updates might corrupt it. The field contains the
The PAPR paravirtualization interface lets guests register three
different types of per-vCPU buffer areas in its memory for communication
with the hypervisor. These are called virtual processor areas (VPAs).
Currently the hypercalls to register and unregister VPAs are handled
by KVM in the
Now that we have an architecture-specific field in the kvm_memory_slot
structure, we can use it to store the array of page physical addresses
that we need for Book3S HV KVM on PPC970 processors. This reduces the
size of struct kvm_arch for Book3S HV, and also reduces the size of
struct
There were a few places where we were traversing the list of runnable
threads in a virtual core, i.e. vc-runnable_threads, without holding
the vcore spinlock. This extends the places where we hold the vcore
spinlock to cover everywhere that we traverse that list.
Since we possibly need to sleep
On 06/19/2012 07:51 AM, Jean-Mickael Guerin wrote:
+if (vq-vring.desc[i].flags VRING_DESC_F_INDIRECT) {
+if (vq-vring.desc[i].len vq-indirect_alloc_thresh)
This should be instead of , no?
It should, yeah.
Too bad slub doesn't yell at you for doing that.
--
To unsubscribe from
Andreas Färber afaer...@suse.de writes:
Hi,
Am 27.08.2012 08:28, schrieb Jan Kiszka:
From: Jan Kiszka jan.kis...@siemens.com
This adds PCI device assignment for i386 targets using the classic KVM
interfaces. This version is 100% identical to what is being maintained
in qemu-kvm for
Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will use indirect
descriptors even if we have plenty of space in the ring. This means that
we take a performance hit at all times due to the overhead of creating
indirect descriptors.
Instead, use it only after we're below a configurable
Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will
use indirect descriptors and allocate them using a simple
kmalloc().
This patch adds a cache which will allow indirect buffers under
a configurable size to be allocated from that cache instead.
Signed-off-by: Sasha Levin
On Tue, Aug 28, 2012 at 03:04:02PM +0200, Sasha Levin wrote:
Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will use indirect
descriptors even if we have plenty of space in the ring. This means that
we take a performance hit at all times due to the overhead of creating
indirect
On Tue, Aug 28, 2012 at 03:04:03PM +0200, Sasha Levin wrote:
Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will
use indirect descriptors and allocate them using a simple
kmalloc().
This patch adds a cache which will allow indirect buffers under
a configurable size to be allocated
It turns out PV EOI gets disabled after migration -
until next guest reset.
This is because we are missing code to actually migrate it.
This patch fixes it up: it applies cleanly to qemu.git
as well as qemu-kvm.git, so I think it's cleaner
to apply it in qemu.git to keep diff to minimum.
Note:
Update linux-headers to version present in Linux 3.6-rc3.
Header asm-x96_64/kvm_para.h update is needed for the new PV EOI
feature.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
linux-headers/asm-s390/kvm.h | 2 +-
linux-headers/asm-s390/kvm_para.h | 2 +-
In preparation to adding PV EOI migration for 1.2,
trivially refactor some some compat code
to make it easier to add version specific
cpuid tweaks.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/pc_piix.c | 44
1 file changed, 36
In preparation for adding PV EOI support, disable PV EOI by default for
1.1 and older machine types, to avoid CPUID changing during migration.
PV EOI can still be enabled/disabled by specifying it explicitly.
Enable for 1.1
-M pc-1.1 -cpu kvm64,+kvm_pv_eoi
Disable for 1.2
-M
Support get/set of new PV EOI MSR, for migration.
Add an optional section for MSR value - send it
out in case MSR was changed from the default value (0).
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
target-i386/cpu.h | 1 +
target-i386/kvm.c | 13 +
On Tue, Aug 28, 2012 at 12:54:54AM +0200, Juan Quintela wrote:
Hi
Please send in any agenda items you are interested in covering.
- *-user and qdev (recent RFCs didn't get many comments in the list, and
I don't see a conclusion);
- 1.2 branching, or creation of a cpu-next tree where good
On 08/28/2012 03:20 PM, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 03:04:03PM +0200, Sasha Levin wrote:
Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will
use indirect descriptors and allocate them using a simple
kmalloc().
This patch adds a cache which will allow indirect
Eduardo Habkost ehabk...@redhat.com wrote:
On Tue, Aug 28, 2012 at 12:54:54AM +0200, Juan Quintela wrote:
Hi
Please send in any agenda items you are interested in covering.
- *-user and qdev (recent RFCs didn't get many comments in the list, and
I don't see a conclusion);
- 1.2
On Tue, Aug 28, 2012 at 03:43:17PM +0200, Juan Quintela wrote:
Eduardo Habkost ehabk...@redhat.com wrote:
On Tue, Aug 28, 2012 at 12:54:54AM +0200, Juan Quintela wrote:
Hi
Please send in any agenda items you are interested in covering.
- *-user and qdev (recent RFCs didn't get
On 28 August 2012 14:30, Eduardo Habkost ehabk...@redhat.com wrote:
- 1.2 branching, or creation of a cpu-next tree where good to be
merged patches can live until 1.2 is done;
With 1.3 due for release in just over a week, it seems unlikely
that it's worth branching at this point...
-- PMM
--
On 08/28/2012 01:54 PM, Paolo Bonzini wrote:
We will place the request virtqueues in the flexible array member.
Refining the virtqueue API would let us drop the sglist copy, at
which point the pointer-to-array-of-pointers can become a simple
pointer-to-array. It would both simplify the
Il 28/08/2012 16:07, Sasha Levin ha scritto:
- num_targets = sh-max_id;
- for (i = 0; i num_targets; i++) {
- kfree(vscsi-tgt[i]);
- vscsi-tgt[i] = NULL;
+ if (vscsi-tgt) {
+ num_targets = sh-max_id;
+ for (i = 0; i num_targets; i++) {
+
On Tue, Aug 28, 2012 at 02:55:56PM +0100, Peter Maydell wrote:
On 28 August 2012 14:30, Eduardo Habkost ehabk...@redhat.com wrote:
- 1.2 branching, or creation of a cpu-next tree where good to be
merged patches can live until 1.2 is done;
With 1.3 due for release in just over a week, it
Hi
As almost everybody was at LinuxCon, we only started talking about the
cpu patches from Eduardo and decided to left things for the list/next
week.
- cpu patches until 1.2
* get a new tree somewhere
- 1.3 discussion will wait until 1.2 is out
people too busy right now
- Remember than KVM
On Tue, 2012-08-28 at 09:23 +, Bhushan Bharat-R65777 wrote:
Hi Alex,
In my susyem I have following devices:
I tried assigning a following PCI devices:
00:03.0 Communication controller: Intel Corporation 4 Series Chipset HECI
Controller (rev 03)
00:03.2 IDE interface: Intel
Avi Kivity a...@redhat.com writes:
On 08/27/2012 02:27 PM, Michael Wolf wrote:
On Mon, 2012-08-27 at 13:31 -0700, Avi Kivity wrote:
On 08/27/2012 01:23 PM, Michael Wolf wrote:
How would a guest know what its entitlement is?
Currently the Admin/management tool setting
On Mon, Aug 27, 2012 at 07:40:56PM +, Blue Swirl wrote:
On Mon, Aug 27, 2012 at 7:24 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Aug 27, 2012 at 07:12:27PM +, Blue Swirl wrote:
On Mon, Aug 27, 2012 at 7:06 PM, Michael S. Tsirkin m...@redhat.com
wrote:
On Mon, Aug 27,
On Tue, Aug 21, 2012 at 05:06:57PM +0300, Avi Kivity wrote:
It turns out that our big real mode implementation was based on a
miconception:
I believed that loading a segment register in real mode causes the limit to be
reset to 0x (thus undoing the effect), while in reality, the limit is
On Mon, Aug 27, 2012 at 03:20:13PM +0300, Michael S. Tsirkin wrote:
In preparation to adding PV EOI migration for 1.2,
trivially refactor some some compat code
to make it easier to add version specific
cpuid tweaks.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/pc_piix.c | 44
On Tue, Aug 28, 2012 at 01:23:18PM -0300, Marcelo Tosatti wrote:
On Mon, Aug 27, 2012 at 03:20:13PM +0300, Michael S. Tsirkin wrote:
In preparation to adding PV EOI migration for 1.2,
trivially refactor some some compat code
to make it easier to add version specific
cpuid tweaks.
On Tue, 28 Aug 2012, Michael S. Tsirkin wrote:
On Mon, Aug 27, 2012 at 07:40:56PM +, Blue Swirl wrote:
On Mon, Aug 27, 2012 at 7:24 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Aug 27, 2012 at 07:12:27PM +, Blue Swirl wrote:
On Mon, Aug 27, 2012 at 7:06 PM, Michael S.
On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev m...@tls.msk.ru wrote:
On 27.08.2012 22:56, Blue Swirl wrote:
[]
+static uint32_t slow_bar_readb(void *opaque, target_phys_addr_t addr)
+{
+AssignedDevRegion *d = opaque;
+uint8_t *in = d-u.r_virtbase + addr;
Don't perform arithmetic
On Tue, Aug 28, 2012 at 1:22 PM, Michael S. Tsirkin m...@redhat.com wrote:
In preparation for adding PV EOI support, disable PV EOI by default for
1.1 and older machine types, to avoid CPUID changing during migration.
PV EOI can still be enabled/disabled by specifying it explicitly.
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Tuesday, August 28, 2012 9:27 PM
To: Bhushan Bharat-R65777
Cc: kvm@vger.kernel.org; Avi Kivity; qemu-de...@nongnu.org
Subject: Re: Isuue assiging devices using VFIO on x86
On Tue, 2012-08-28 at
On 8/28/12 12:35 AM, Andrew Jones wrote:
This is the second user. As I said, move the stats code from
builtin-stat.c. Or are you suggesting to duplicate the code once,
and then refactor the second (really the third) time it's needed?
gah, I misunderstood your comment. I see your point now.
On Tue, Aug 28, 2012 at 05:05:25PM +, Blue Swirl wrote:
+static bool _kvm_pv_eoi_disabled;
NACK. I find your lack of compliance disturbing.
Compliance with what? Could you please add some
motivation for the NACK?
--
MST
--
To unsubscribe from this list: send the line unsubscribe kvm in
On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl wrote:
On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev m...@tls.msk.ru wrote:
On 27.08.2012 22:56, Blue Swirl wrote:
[]
+static uint32_t slow_bar_readb(void *opaque, target_phys_addr_t addr)
+{
+AssignedDevRegion *d = opaque;
+
On Tue, Aug 28, 2012 at 5:22 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 05:05:25PM +, Blue Swirl wrote:
+static bool _kvm_pv_eoi_disabled;
NACK. I find your lack of compliance disturbing.
Compliance with what? Could you please add some
motivation for the
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl wrote:
On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev m...@tls.msk.ru wrote:
On 27.08.2012 22:56, Blue Swirl wrote:
[]
+static uint32_t slow_bar_readb(void
On Tue, Aug 28, 2012 at 05:28:22PM +, Blue Swirl wrote:
On Tue, Aug 28, 2012 at 5:22 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 05:05:25PM +, Blue Swirl wrote:
+static bool _kvm_pv_eoi_disabled;
NACK. I find your lack of compliance disturbing.
It turns out PV EOI gets disabled after migration -
until next guest reset.
This is because we are missing code to actually migrate it.
This patch fixes it up: it applies cleanly to qemu.git
as well as qemu-kvm.git, so I think it's cleaner
to apply it in qemu.git to keep diff to minimum.
Note:
Update linux-headers to version present in Linux 3.6-rc3.
Header asm-x96_64/kvm_para.h update is needed for the new PV EOI
feature.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
linux-headers/asm-s390/kvm.h | 2 +-
linux-headers/asm-s390/kvm_para.h | 2 +-
In preparation to adding PV EOI migration for 1.2,
trivially refactor some some compat code
to make it easier to add version specific
cpuid tweaks.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/pc_piix.c | 44
1 file changed, 36
In preparation for adding PV EOI support, disable PV EOI by default for
1.1 and older machine types, to avoid CPUID changing during migration.
PV EOI can still be enabled/disabled by specifying it explicitly.
Enable for 1.1
-M pc-1.1 -cpu kvm64,+kvm_pv_eoi
Disable for 1.2
-M
Support get/set of new PV EOI MSR, for migration.
Add an optional section for MSR value - send it
out in case MSR was changed from the default value (0).
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
target-i386/cpu.h | 1 +
target-i386/kvm.c | 13 +
Am 28.08.2012 16:27, schrieb Eduardo Habkost:
On Tue, Aug 28, 2012 at 02:55:56PM +0100, Peter Maydell wrote:
On 28 August 2012 14:30, Eduardo Habkost ehabk...@redhat.com wrote:
- 1.2 branching, or creation of a cpu-next tree where good to be
merged patches can live until 1.2 is done;
With
On Tue, Aug 28, 2012 at 07:59:47PM +0200, Andreas Färber wrote:
Am 28.08.2012 16:27, schrieb Eduardo Habkost:
On Tue, Aug 28, 2012 at 02:55:56PM +0100, Peter Maydell wrote:
On 28 August 2012 14:30, Eduardo Habkost ehabk...@redhat.com wrote:
- 1.2 branching, or creation of a cpu-next tree
On Tue, Aug 28, 2012 at 07:31:24PM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 01:23:18PM -0300, Marcelo Tosatti wrote:
On Mon, Aug 27, 2012 at 03:20:13PM +0300, Michael S. Tsirkin wrote:
In preparation to adding PV EOI migration for 1.2,
trivially refactor some some compat
On Tue, Aug 28, 2012 at 08:43:52PM +0300, Michael S. Tsirkin wrote:
In preparation for adding PV EOI support, disable PV EOI by default for
1.1 and older machine types, to avoid CPUID changing during migration.
PV EOI can still be enabled/disabled by specifying it explicitly.
Enable for
Michael S. Tsirkin m...@redhat.com writes:
In preparation for adding PV EOI support, disable PV EOI by default for
1.1 and older machine types, to avoid CPUID changing during migration.
PV EOI can still be enabled/disabled by specifying it explicitly.
Enable for 1.1
-M pc-1.1 -cpu
Eduardo Habkost ehabk...@redhat.com writes:
On Tue, Aug 28, 2012 at 07:59:47PM +0200, Andreas Färber wrote:
Am 28.08.2012 16:27, schrieb Eduardo Habkost:
On Tue, Aug 28, 2012 at 02:55:56PM +0100, Peter Maydell wrote:
On 28 August 2012 14:30, Eduardo Habkost ehabk...@redhat.com wrote:
-
On Tue, Aug 28, 2012 at 02:15:30PM -0500, Anthony Liguori wrote:
Eduardo Habkost ehabk...@redhat.com writes:
On Tue, Aug 28, 2012 at 07:59:47PM +0200, Andreas Färber wrote:
Am 28.08.2012 16:27, schrieb Eduardo Habkost:
On Tue, Aug 28, 2012 at 02:55:56PM +0100, Peter Maydell wrote:
On
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl wrote:
On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev m...@tls.msk.ru wrote:
On 27.08.2012 22:56, Blue Swirl wrote:
[]
On Tue, Aug 28, 2012 at 02:13:18PM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
In preparation for adding PV EOI support, disable PV EOI by default for
1.1 and older machine types, to avoid CPUID changing during migration.
PV EOI can still be enabled/disabled
On Tue, 28 Aug 2012, Anthony Liguori wrote:
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl wrote:
On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev m...@tls.msk.ru
Eduardo Habkost ehabk...@redhat.com writes:
On Tue, Aug 28, 2012 at 02:15:30PM -0500, Anthony Liguori wrote:
Eduardo Habkost ehabk...@redhat.com writes:
On Tue, Aug 28, 2012 at 07:59:47PM +0200, Andreas Färber wrote:
Am 28.08.2012 16:27, schrieb Eduardo Habkost:
On Tue, Aug 28, 2012 at
On Tue, Aug 28, 2012 at 7:31 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl wrote:
On Tue, Aug 28, 2012 at 7:35 AM, Michael
Other arches do not need this.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
v2: fix incorrect deletion of mmio sptes on gpa move (noticed by Takuya)
Index: kvm/arch/x86/kvm/x86.c
===
--- kvm.orig/arch/x86/kvm/x86.c
+++
On Tue, Aug 28, 2012 at 09:30:24AM +0900, Takuya Yoshikawa wrote:
On Mon, 27 Aug 2012 16:06:01 -0300
Marcelo Tosatti mtosa...@redhat.com wrote:
Any explanation why (old.base_gfn != new.base_gfn) case can be
omitted?
(old.base_gfn != new.base_gfn) check covers the cases
1.
On Mon, Aug 27, 2012 at 04:04:44PM +0800, Xiao Guangrong wrote:
On 08/25/2012 02:54 AM, Marcelo Tosatti wrote:
Other arches do not need this.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: kvm/arch/x86/kvm/x86.c
My vm launches with -hda /dev/turtle/VD0 -hdb /dev/turtle/VD1, where VD0
and VD1 are lvm logical volumes. I used lvextend to expand them, but
the VM, started after the expansion, does not seem to see the extra
space.
What do I need to so that the space will be recognized?
The net has references
On Tue, Aug 28, 2012 at 1:26 PM, Ross Boylan r...@biostat.ucsf.edu wrote:
My vm launches with -hda /dev/turtle/VD0 -hdb /dev/turtle/VD1, where VD0
and VD1 are lvm logical volumes. I used lvextend to expand them, but
the VM, started after the expansion, does not seem to see the extra
space.
On 27 August 2012 13:15, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-08-27 14:07, Andreas Färber wrote:
Am I correct to understand we compile this only for i386 / x86_64?
This is correct.
Did we ever make a decision about whether architecture specific
KVM devices should all live in
On Tue, Aug 28, 2012 at 01:37:18PM -0300, Marcelo Tosatti wrote:
On Tue, Aug 28, 2012 at 07:31:24PM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 01:23:18PM -0300, Marcelo Tosatti wrote:
On Mon, Aug 27, 2012 at 03:20:13PM +0300, Michael S. Tsirkin wrote:
In preparation to
On Tue, 28 Aug 2012 16:26:38 -0400, Ross Boylan r...@biostat.ucsf.edu
wrote:
What do I need to so that the space will be recognized?
your partition table for hd{a,b} within the guest is also now wrong. the
correct way to add more space is to add another disk and then use LVM
inside the
On Tue, 2012-08-28 at 14:15 -0700, Freddie Cash wrote:
On Tue, Aug 28, 2012 at 1:26 PM, Ross Boylan r...@biostat.ucsf.edu wrote:
My vm launches with -hda /dev/turtle/VD0 -hdb /dev/turtle/VD1, where VD0
and VD1 are lvm logical volumes. I used lvextend to expand them, but
the VM, started
On Tue, Aug 28, 2012 at 04:13:38PM -0300, Eduardo Habkost wrote:
On Tue, Aug 28, 2012 at 08:43:52PM +0300, Michael S. Tsirkin wrote:
In preparation for adding PV EOI support, disable PV EOI by default for
1.1 and older machine types, to avoid CPUID changing during migration.
PV EOI can
On Tue, Aug 28, 2012 at 02:13:18PM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
In preparation for adding PV EOI support, disable PV EOI by default for
1.1 and older machine types, to avoid CPUID changing during migration.
PV EOI can still be enabled/disabled
On Tue, Aug 28, 2012 at 04:40:38PM -0300, Eduardo Habkost wrote:
On Tue, Aug 28, 2012 at 02:13:18PM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
In preparation for adding PV EOI support, disable PV EOI by default for
1.1 and older machine types, to avoid
On Tue, Aug 28, 2012 at 2:33 PM, Matthew Patton mpat...@inforelay.com wrote:
On Tue, 28 Aug 2012 16:26:38 -0400, Ross Boylan r...@biostat.ucsf.edu
wrote:
What do I need to so that the space will be recognized?
your partition table for hd{a,b} within the guest is also now wrong. the
correct
On Tue, Aug 28, 2012 at 01:02:26PM +0200, Jan Kiszka wrote:
This adds PCI device assignment for i386 targets using the classic KVM
interfaces. This version is 100% identical to what is being maintained
in qemu-kvm for several years and is supported by libvirt as well. It is
expected to remain
On Tue, Aug 28, 2012 at 09:02:05PM +0400, malc wrote:
On Tue, 28 Aug 2012, Michael S. Tsirkin wrote:
On Mon, Aug 27, 2012 at 07:40:56PM +, Blue Swirl wrote:
On Mon, Aug 27, 2012 at 7:24 PM, Michael S. Tsirkin m...@redhat.com
wrote:
On Mon, Aug 27, 2012 at 07:12:27PM +, Blue
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 7:31 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl
On Wed, Aug 29, 2012 at 12:35:28AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 04:13:38PM -0300, Eduardo Habkost wrote:
On Tue, Aug 28, 2012 at 08:43:52PM +0300, Michael S. Tsirkin wrote:
In preparation for adding PV EOI support, disable PV EOI by default for
1.1 and older
On Tue, Aug 28, 2012 at 07:02:42PM -0300, Eduardo Habkost wrote:
On Wed, Aug 29, 2012 at 12:35:28AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 04:13:38PM -0300, Eduardo Habkost wrote:
On Tue, Aug 28, 2012 at 08:43:52PM +0300, Michael S. Tsirkin wrote:
In preparation for
On Wed, Aug 29, 2012 at 01:21:13AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 07:02:42PM -0300, Eduardo Habkost wrote:
On Wed, Aug 29, 2012 at 12:35:28AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 04:13:38PM -0300, Eduardo Habkost wrote:
On Tue, Aug 28, 2012
Hi all,
This compiles, completely untested, but it's my attempt to give
Avi (and Alexander) what he asked for in a generic register accessor.
Mingled in these patches is the conversion of the latest KVM ARM code,
which is the first proposed user: by the end, we use these accessors for
On Wed, Aug 29, 2012 at 01:25:35AM +0300, Michael S. Tsirkin wrote:
On Wed, Aug 29, 2012 at 01:21:13AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 28, 2012 at 07:02:42PM -0300, Eduardo Habkost wrote:
On Wed, Aug 29, 2012 at 12:35:28AM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 28,
1 - 100 of 124 matches
Mail list logo
