That's virtio, not IDE.
well, this seems a bit strange to me, the only virtio device I can
see is balloon dev, can this be it?
how can I find out which operations are IDE PIO etc? sorry
for asking silly questions, but I couldn't find this anywhere
in the documentation...
thanks in advance
nik
On 02/06/2012 10:51 AM, Christian Hoff wrote:
Hello Paolo,
first let me say that your patch is working fine on my local clone of the
qemu repository.
Let me ask just one question about the format of the data being
transmitted over the virtqueue.
Paolo Bonzini wrote:
+
On 07.02.2012, at 07:58, Michael Ellerman wrote:
On Mon, 2012-02-06 at 13:46 -0600, Scott Wood wrote:
On 02/03/2012 04:52 PM, Anthony Liguori wrote:
On 02/03/2012 12:07 PM, Eric Northup wrote:
On Thu, Feb 2, 2012 at 8:09 AM, Avi Kivitya...@redhat.com wrote:
[...]
Moving to syscalls
On Tue, Feb 07, 2012 at 10:54:54AM +0100, Paolo Bonzini wrote:
Also, lun[1] = sc-device-id means that only 255 SCSI target IDs will be
supported. Think about bigger usage scenarios, such as FCP networks with
several hundred HBAs in the net. If you want to have the target ID-HBA
mapping the
On 02/07/2012 12:10 PM, Michael S. Tsirkin wrote:
Also, lun[1] = sc-device-id means that only 255 SCSI target IDs will be
supported. Think about bigger usage scenarios, such as FCP networks with
several hundred HBAs in the net. If you want to have the target ID-HBA
mapping the same as on
+cmd-req.cmd = (struct virtio_scsi_cmd_req){
+.lun[0] = 1,
+.lun[1] = sc-device-id,
+.lun[2] = (sc-device-lun 8) | 0x40,
+.lun[3] = sc-device-lun
On 02/06/2012 07:41 PM, Rob Earhart wrote:
I like the ioctl() interface. If the overhead matters in your hot path,
I can't say that it's a pressing problem, but it's not negligible.
I suspect you're doing it wrong;
What am I doing wrong?
You the vmm not you the KVM maintainer :-)
On 02/06/2012 09:11 PM, Anthony Liguori wrote:
I'm not so sure. ioeventfds and a future mmio-over-socketpair have to
put the kthread to sleep while it waits for the other end to process
it. This is effectively equivalent to a heavy weight exit. The
difference in cost is dropping to
On 02/07/2012 03:08 AM, Alexander Graf wrote:
I don't like the idea too much. On s390 and ppc we can set other vcpu's
interrupt status. How would that work in this model?
It would be a vm-wide syscall. You can also do that on x86 (through
KVM_IRQ_LINE).
I really do like the ioctl model
On 02/06/2012 01:46 PM, Scott Wood wrote:
On 02/03/2012 04:52 PM, Anthony Liguori wrote:
On 02/03/2012 12:07 PM, Eric Northup wrote:
On Thu, Feb 2, 2012 at 8:09 AM, Avi Kivitya...@redhat.com wrote:
[...]
Moving to syscalls avoids these problems, but introduces new ones:
- adding new
On 02/07/2012 12:56 PM, Christian Borntraeger wrote:
The 14-bit limitation can be lifted. SAM defines a 24-bit LUN format too,
but I've never seen it used in practice.
Why not lift that limitation before the first version is committed upstream?
Because nobody supports 14-bit LUNs. The
On 02/07/2012 02:28 PM, Anthony Liguori wrote:
It's a potential source of exploits
(from bugs in KVM or in hardware). I can see people wanting to be
selective with access because of that.
As is true of the rest of the kernel.
If you want finer grain access control, that's exactly why we
On 02/07/2012 06:40 AM, Avi Kivity wrote:
On 02/07/2012 02:28 PM, Anthony Liguori wrote:
It's a potential source of exploits
(from bugs in KVM or in hardware). I can see people wanting to be
selective with access because of that.
As is true of the rest of the kernel.
If you want finer
On 07.02.2012, at 13:24, Avi Kivity wrote:
On 02/07/2012 03:08 AM, Alexander Graf wrote:
I don't like the idea too much. On s390 and ppc we can set other vcpu's
interrupt status. How would that work in this model?
It would be a vm-wide syscall. You can also do that on x86 (through
They are needed by 'perf kvm-events'
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/include/asm/kvm_host.h | 36 ---
arch/x86/include/asm/svm.h | 205 +--
arch/x86/include/asm/vmx.h | 125
'perf kvm-events' will use kvm_exit and kvm_mmio(read...) to calculate
mmio read emulated time for the old kernel, in order to trace mmio read
event more exactly, we add kvm_mmio_begin to trace the time when mmio read
begins
Also, add kvm_mmio_done to trace the time when mmio/pio is completed
Add 'perf kvm-events' support to analyze kvm vmexit/mmio/ioport smartly
Usage:
- trace kvm events:
perf kvm-events record, or, if other tracepoints are also
interesting, we can append the events like this:
perf kvm-events record -e timer:*
- show the result:
perf
On 02/07/2012 02:51 PM, Alexander Graf wrote:
On 07.02.2012, at 13:24, Avi Kivity wrote:
On 02/07/2012 03:08 AM, Alexander Graf wrote:
I don't like the idea too much. On s390 and ppc we can set other vcpu's
interrupt status. How would that work in this model?
It would be a vm-wide
On 07/02/12 13:31, Paolo Bonzini wrote:
The structure of the LUN is defined by SAM, not by me.
Ok, got it.
--
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 02/07/2012 02:51 PM, Anthony Liguori wrote:
On 02/07/2012 06:40 AM, Avi Kivity wrote:
On 02/07/2012 02:28 PM, Anthony Liguori wrote:
It's a potential source of exploits
(from bugs in KVM or in hardware). I can see people wanting to be
selective with access because of that.
As is true of
On 07.02.2012, at 14:16, Avi Kivity wrote:
On 02/07/2012 02:51 PM, Alexander Graf wrote:
On 07.02.2012, at 13:24, Avi Kivity wrote:
On 02/07/2012 03:08 AM, Alexander Graf wrote:
I don't like the idea too much. On s390 and ppc we can set other vcpu's
interrupt status. How would that
Am 06.02.2012 20:25, schrieb Juan Quintela:
Please send in any agenda items you are interested in covering.
I had some follow-up questions to the last call that remained
unanswered. We don't really need a call for that though, email is fine.
On 02/07/2012 02:45 PM, Andreas Färber wrote:
Another topic that can be answered by email is what the time planning
for the 4th QOM series looks like. Are there things that developers of
new devices should keep in mind / start doing differently wrt SysBus?
Another related question is, should
Hello Paolo,
On 07/02/12 13:31, Paolo Bonzini wrote:
The structure of the LUN is defined by SAM, not by me.
Just had a look at the SAM LUN structure. It appears that you are using
the SCSI format for hierarchical LUNs(SAM 5 chapter 4.7.6) in order to
indicate that the LUN is actually
On 02/07/2012 03:40 PM, Alexander Graf wrote:
Not sure we'll ever get there. For PPC, it will probably take another 1-2
years until we get the 32-bit targets stabilized. By then we will have new 64-bit
support though. And then the next gen will come out giving us even more new
constraints.
On 02/07/2012 02:59 PM, Christian Hoff wrote:
Instead the format has some disadvantages:
- It uses up 8 bytes where 3 bytes would be sufficient in order to store
both the target ID and LUN number information
- The format limits us to 255 target IDs. I agree that the LUN limit is
probably more a
On 07.02.2012, at 15:21, Avi Kivity wrote:
On 02/07/2012 03:40 PM, Alexander Graf wrote:
Not sure we'll ever get there. For PPC, it will probably take another
1-2 years until we get the 32-bit targets stabilized. By then we will
have new 64-bit support though. And then the next gen
Juan Quintela quint...@redhat.com wrote:
Hi
Please send in any agenda items you are interested in covering.
As there were only one topic for the call, and Andreas suggested to use
email, we cancel this week call.
Have a nice day, Juan.
--
To unsubscribe from this list: send the line
When kvm guest uses kvmclock, it may hang on vcpu hot-plug.
This is caused by an overflow in pvclock_get_nsec_offset,
u64 delta = tsc - shadow-tsc_timestamp;
which in turn is caused by an undefined values from percpu
hv_clock that hasn't been initialized yet.
Uninitialized clock on being
On 02/07/2012 07:52 AM, Paolo Bonzini wrote:
On 02/07/2012 02:45 PM, Andreas Färber wrote:
Another topic that can be answered by email is what the time planning
for the 4th QOM series looks like.
qom-upstream.16 is pretty close to ready to be sent out for v1. It's fairly
tricky getting
On Tue, Jan 31, 2012 at 8:29 PM, Orit Wasserman owass...@redhat.com wrote:
On 01/31/2012 05:35 AM, Zhi Yong Wu wrote:
HI,
Can anyone let me know know the difference between VMXON region and
VMCS region? relationship?
There is no relationship between them:
VMXON region is created per
On Tue, 2012-02-07 at 08:31 +0200, Michael S. Tsirkin wrote:
On Mon, Feb 06, 2012 at 02:46:29PM -0700, Alex Williamson wrote:
On Tue, 2012-01-31 at 21:11 +0200, Michael S. Tsirkin wrote:
On Mon, Jan 30, 2012 at 02:05:54PM -0700, Alex Williamson wrote:
We need to prioritize our matching
On 02/07/2012 07:18 AM, Avi Kivity wrote:
On 02/07/2012 02:51 PM, Anthony Liguori wrote:
On 02/07/2012 06:40 AM, Avi Kivity wrote:
On 02/07/2012 02:28 PM, Anthony Liguori wrote:
It's a potential source of exploits
(from bugs in KVM or in hardware). I can see people wanting to be
selective
On 02/07/2012 06:03 AM, Avi Kivity wrote:
On 02/06/2012 09:11 PM, Anthony Liguori wrote:
I'm not so sure. ioeventfds and a future mmio-over-socketpair have to put the
kthread to sleep while it waits for the other end to process it. This is
effectively equivalent to a heavy weight exit. The
On 02/07/2012 03:56 PM, Anthony Liguori wrote:
Another related question is, should the 4th QOM series present a full
composition tree based on the legacy qdev bus concept?
Composition, no. The legacy qbus concept doesn't model composition
because it puts children created by composition (like
On 02/07/2012 07:40 AM, Alexander Graf wrote:
Why? For the HPET timer register for example, we could have a simple MMIO hook
that says
on_read:
return read_current_time() - shared_page.offset;
on_write:
handle_in_user_space();
For IDE, it would be as simple as
On 07.02.2012, at 16:23, Anthony Liguori wrote:
On 02/07/2012 07:40 AM, Alexander Graf wrote:
Why? For the HPET timer register for example, we could have a simple MMIO
hook that says
on_read:
return read_current_time() - shared_page.offset;
on_write:
We're building a virtual windows 7 x64 model on top of a custom Linux OS.
We're currently using 2.6.38.8 kernel.
I was rather attracted to the new kvm-apic/qemu-kvm merge you've currently
made available, as this may hold the answer to a stubborn problem;
every time we load or attempt to create a
On Tue, Feb 07, 2012 at 08:11:30AM -0700, Alex Williamson wrote:
On Tue, 2012-02-07 at 08:31 +0200, Michael S. Tsirkin wrote:
On Mon, Feb 06, 2012 at 02:46:29PM -0700, Alex Williamson wrote:
On Tue, 2012-01-31 at 21:11 +0200, Michael S. Tsirkin wrote:
On Mon, Jan 30, 2012 at 02:05:54PM
On 02/07/2012 05:17 PM, Anthony Liguori wrote:
On 02/07/2012 06:03 AM, Avi Kivity wrote:
On 02/06/2012 09:11 PM, Anthony Liguori wrote:
I'm not so sure. ioeventfds and a future mmio-over-socketpair have
to put the
kthread to sleep while it waits for the other end to process it.
This is
On 2012-02-07 16:25, Simon wrote:
We're building a virtual windows 7 x64 model on top of a custom Linux OS.
We're currently using 2.6.38.8 kernel.
I was rather attracted to the new kvm-apic/qemu-kvm merge you've currently
made available, as this may hold the answer to a stubborn problem;
On 2012-02-07 17:02, Avi Kivity wrote:
On 02/07/2012 05:17 PM, Anthony Liguori wrote:
On 02/07/2012 06:03 AM, Avi Kivity wrote:
On 02/06/2012 09:11 PM, Anthony Liguori wrote:
I'm not so sure. ioeventfds and a future mmio-over-socketpair have
to put the
kthread to sleep while it waits for
On 02/07/2012 10:02 AM, Avi Kivity wrote:
On 02/07/2012 05:17 PM, Anthony Liguori wrote:
On 02/07/2012 06:03 AM, Avi Kivity wrote:
On 02/06/2012 09:11 PM, Anthony Liguori wrote:
I'm not so sure. ioeventfds and a future mmio-over-socketpair have to put the
kthread to sleep while it waits for
On 02/07/2012 10:18 AM, Jan Kiszka wrote:
On 2012-02-07 17:02, Avi Kivity wrote:
On 02/07/2012 05:17 PM, Anthony Liguori wrote:
On 02/07/2012 06:03 AM, Avi Kivity wrote:
On 02/06/2012 09:11 PM, Anthony Liguori wrote:
I'm not so sure. ioeventfds and a future mmio-over-socketpair have
to put
On 02/07/2012 09:21 AM, Paolo Bonzini wrote:
On 02/07/2012 03:56 PM, Anthony Liguori wrote:
Another related question is, should the 4th QOM series present a full
composition tree based on the legacy qdev bus concept?
Composition, no. The legacy qbus concept doesn't model composition
because
On 02/07/2012 05:24 PM, Anthony Liguori wrote:
I'm wary of all plans that require to go through all the code once. What about
simply /devices/default/child[...] or something like that?
The paths would be unstable, but maybe that's okay. I'd suggest
doing child[rand()] to avoid the appearance
On 2012-02-07 17:21, Anthony Liguori wrote:
On 02/07/2012 10:18 AM, Jan Kiszka wrote:
On 2012-02-07 17:02, Avi Kivity wrote:
On 02/07/2012 05:17 PM, Anthony Liguori wrote:
On 02/07/2012 06:03 AM, Avi Kivity wrote:
On 02/06/2012 09:11 PM, Anthony Liguori wrote:
I'm not so sure. ioeventfds
On 02/07/2012 10:27 AM, Paolo Bonzini wrote:
On 02/07/2012 05:24 PM, Anthony Liguori wrote:
I'm wary of all plans that require to go through all the code once. What about
simply /devices/default/child[...] or something like that?
The paths would be unstable, but maybe that's okay. I'd suggest
On 7 February 2012 16:33, Anthony Liguori anth...@codemonkey.ws wrote:
OMAP clocks are devices. Don't they belong in the devices hierarchy under
the omap-clocks branch?
I think they should be interfaces, not devices. The device would be the PRCM
(power, reset and clock manager) which provides
Am 07.02.2012 16:21, schrieb Paolo Bonzini:
BTW, I would like to change /i440fx to /devices/i440fx, so that we will
have clean namespaces:
/block
...
/chardev
...
/clocks
...
/devices
/peripheral
... # named devices created with -device
On 02/07/2012 10:41 AM, Andreas Färber wrote:
Am 07.02.2012 16:21, schrieb Paolo Bonzini:
BTW, I would like to change /i440fx to /devices/i440fx, so that we will
have clean namespaces:
/block
...
/chardev
...
/clocks
...
/devices
/peripheral
... #
On 02/07/2012 05:33 PM, Anthony Liguori wrote:
Hrm, I don't like that very much.
Yes, me neither actually.
If the object representing the state of the OMAP board (struct
omap_mpu_state_s) is QOMified, the clocks can easily get under it in the
composition tree. Right now, that part is not
On Tue, 7 Feb 2012, Igor Mammedov wrote:
When kvm guest uses kvmclock, it may hang on vcpu hot-plug.
This is caused by an overflow in pvclock_get_nsec_offset,
u64 delta = tsc - shadow-tsc_timestamp;
which in turn is caused by an undefined values from percpu
hv_clock that hasn't been
On Mon, Jan 30, 2012 at 12:48:59PM +0900, Takuya Yoshikawa wrote:
This is the first step to separate the architecture specific members.
The rmap and dirty_bitmap can be treated later based on this.
v1-v2:
Patch 3:
- Removed extra checks for NULL when we create a new slot.
- Removed
yield_on_hlt was introduced for CPU bandwidth capping. now it is redundant
with CFS hardlimit.
yield_on_hlt also complicates the scenario in paravirtual environment, that
needs to trap halt. for e.g. paravirtualized ticket spinlocks.
Changelog:
Remove the support for yield_on_hlt.
On 02/07/2012 06:08 AM, Xiao Guangrong wrote:
Add 'perf kvm-events' support to analyze kvm vmexit/mmio/ioport smartly
example output?
Usage:
- trace kvm events:
perf kvm-events record, or, if other tracepoints are also
interesting, we can append the events like this:
On 02/07/2012 07:45 AM, Andreas Färber wrote:
Am 06.02.2012 20:25, schrieb Juan Quintela:
Please send in any agenda items you are interested in covering.
I had some follow-up questions to the last call that remained
unanswered. We don't really need a call for that though, email is fine.
On 02/07/2012 11:49 AM, Raghavendra K T wrote:
yield_on_hlt was introduced for CPU bandwidth capping. now it is redundant
with CFS hardlimit.
yield_on_hlt also complicates the scenario in paravirtual environment, that
needs to trap halt. for e.g. paravirtualized ticket spinlocks.
Changelog:
Am 07.02.2012 19:01, schrieb Anthony Liguori:
On 02/07/2012 07:45 AM, Andreas Färber wrote:
http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg04065.html
How is the realize step (DeviceState::init) supposed to translate to
Object-derived classes (e.g., CPU) and where to draw the line
* Anthony Liguori (anth...@codemonkey.ws) wrote:
On 02/07/2012 07:18 AM, Avi Kivity wrote:
On 02/07/2012 02:51 PM, Anthony Liguori wrote:
On 02/07/2012 06:40 AM, Avi Kivity wrote:
On 02/07/2012 02:28 PM, Anthony Liguori wrote:
It's a potential source of exploits
(from bugs in KVM or in
On 02/07/2012 12:17 PM, Andreas Färber wrote:
Am 07.02.2012 19:01, schrieb Anthony Liguori:
On 02/07/2012 07:45 AM, Andreas Färber wrote:
http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg04065.html
How is the realize step (DeviceState::init) supposed to translate to
Object-derived
On Tue, Jan 31, 2012 at 07:17:52PM +0100, Jan Kiszka wrote:
To both avoid that kvm_irqchip_in_kernel always has to be paired with
kvm_enabled and that the former ends up in a function call, implement it
like the latter. This means keeping the state in a global variable and
defining
On Tue, Jan 31, 2012 at 10:35:31AM -0500, Eric B Munson wrote:
Now that we have a flag that will tell the guest it was suspended, create an
interface for that communication using a KVM ioctl.
Signed-off-by: Eric B Munson emun...@mgebm.net
Cc: mi...@redhat.com
Cc: h...@zytor.com
Cc:
On Tue, Jan 31, 2012 at 10:35:30AM -0500, Eric B Munson wrote:
When a host stops or suspends a VM it will set a flag to show this. The
watchdog will use these functions to determine if a softlockup is real, or the
result of a suspended VM.
Signed-off-by: Eric B Munson emun...@mgebm.net
On Tue, Feb 07, 2012 at 05:32:07PM +1100, Michael Ellerman wrote:
A test case which does the following:
ioctl(vmfd, KVM_CREATE_VCPU, 0);
ioctl(vmfd, KVM_CREATE_IRQCHIP);
ioctl(cpufd, KVM_RUN);
Can oops in kvm_apic_accept_pic_intr() because vcpu-arch.apic == NULL.
Because
On Tue, Jan 31, 2012 at 10:32:15PM -0700, Alex Williamson wrote:
This series enables better runtime MSI-X table support so
that we can track vector updates for routing, enabling
guest interrupt smp_affinity, as well as vectors setup
after the MSI-X PCI capability is enabled, allowing for
On Tue, Feb 07, 2012 at 03:52:44PM +0100, Igor Mammedov wrote:
When kvm guest uses kvmclock, it may hang on vcpu hot-plug.
This is caused by an overflow in pvclock_get_nsec_offset,
u64 delta = tsc - shadow-tsc_timestamp;
which in turn is caused by an undefined values from percpu
On Mon, 06 Feb 2012 11:34:01 +0200, Avi Kivity a...@redhat.com wrote:
On 02/05/2012 06:36 PM, Anthony Liguori wrote:
If userspace had a way to upload bytecode to the kernel that was
executed for a PIO operation, it could either pass the operation to
userspace or handle it within the kernel
Hello all, I hope someone may point me in a direction to take.
I am running KVM on SLES SP1 with a SLES 11 Guest. Recently I noticed that the
host console
was hung. I was able to SSH into the running Guest and shut it down but was
unable to regain control
over the host. The keyboard, mouse and
Upon resume from hibernation, CPU 0's hvclock area contains the old
values for system_time and tsc_timestamp. It is necessary for the
hypervisor to update these values with uptodate ones before the CPU uses
them.
Abstract TSC's save/restore sched_clock_state functions and use
restore_state to
On Tue, Feb 07, 2012 at 11:19:20PM +0530, Raghavendra K T wrote:
yield_on_hlt was introduced for CPU bandwidth capping. now it is redundant
with CFS hardlimit.
yield_on_hlt also complicates the scenario in paravirtual environment, that
needs to trap halt. for e.g. paravirtualized ticket
This flag will be used to check if the vm was stopped by the host when a soft
lockup was detected. The host will set the flag when it stops the guest. On
resume, the guest will check this flag if a soft lockup is detected and skip
issuing the warning.
Signed-off-by: Eric B Munson
Now that we have a flag that will tell the guest it was suspended, create an
interface for that communication using a KVM ioctl.
Signed-off-by: Eric B Munson emun...@mgebm.net
Cc: mi...@redhat.com
Cc: h...@zytor.com
Cc: ry...@linux.vnet.ibm.com
Cc: aligu...@us.ibm.com
Cc: mtosa...@redhat.com
Cc:
Changes from V11:
Re-add asm-generic stub
Correct api.txt typo
add kvm_make_request() call after setting PVCLOCK_GUEST_STOPPED
Changes from V10:
Return ioctl to per vcpu instead of per vm
Changes from V9:
Use kvm_for_each_vcpu to iterate online vcpu's
Changes from V8:
Make KVM_GUEST_PAUSED a
On 2012-02-07 19:59, Marcelo Tosatti wrote:
On Tue, Jan 31, 2012 at 10:35:31AM -0500, Eric B Munson wrote:
Now that we have a flag that will tell the guest it was suspended, create an
interface for that communication using a KVM ioctl.
Signed-off-by: Eric B Munson emun...@mgebm.net
Cc:
A suspended VM can cause spurious soft lockup warnings. To avoid these, the
watchdog now checks if the kernel knows it was stopped by the host and skips
the warning if so. When the watchdog is reset successfully, clear the guest
paused flag.
Signed-off-by: Eric B Munson emun...@mgebm.net
Cc:
When a host stops or suspends a VM it will set a flag to show this. The
watchdog will use these functions to determine if a softlockup is real, or the
result of a suspended VM.
Signed-off-by: Eric B Munson emun...@mgebm.net
asm-generic changes Acked-by: Arnd Bergmann a...@arndb.de
Cc:
I managed to miss the discussion from the V11 thread, I will work those
comments in tomorrow and send V13 as soon as that is done.
Eric
--
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 Wed, Feb 8, 2012 at 1:52 AM, Orit Wasserman owass...@redhat.com wrote:
On 02/07/2012 05:09 PM, Zhi Yong Wu wrote:
On Tue, Jan 31, 2012 at 8:29 PM, Orit Wasserman owass...@redhat.com wrote:
On 01/31/2012 05:35 AM, Zhi Yong Wu wrote:
HI,
Can anyone let me know know the difference between
Rebased the whole series (against the next branch of kvm.git).
No manual edit.
If something is still wrong, please let me know.
Thanks,
Takuya
---
This is the first step to separate the architecture specific members.
The rmap and dirty_bitmap can be treated later based on this.
v4:
This patch cleans up the code and removes the (void)level; warning
suppressor.
Note that we can also use this for PT_PAGE_TABLE_LEVEL to treat every
level uniformly later.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
arch/x86/kvm/mmu.c |3 +--
This makes it easy to make lpage_info architecture specific.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
virt/kvm/kvm_main.c | 83 ---
1 files changed, 52 insertions(+), 31 deletions(-)
diff --git a/virt/kvm/kvm_main.c
Narrow down the controlled text inside the conditional so that it will
include lpage_info and rmap stuff only.
For this we change the way we check whether the slot is being created
from if (npages !new.rmap) to if (npages !old.npages).
We also stop checking if lpage_info is NULL when we create
Some members of kvm_memory_slot are not used by every architecture.
This patch is the first step to make this difference clear by
introducing kvm_memory_slot::arch; lpage_info is moved into it.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
arch/ia64/include/asm/kvm_host.h
The Buildbot has detected a new failure on builder next-i386 while building kvm.
Full details are available at:
http://buildbot.b1-systems.de/kvm/builders/next-i386/builds/436
Buildbot URL: http://buildbot.b1-systems.de/kvm/
Buildslave for this Build: b1_kvm_1
Build Reason: The Nightly
On 02/08/2012 01:55 AM, David Ahern wrote:
On 02/07/2012 06:08 AM, Xiao Guangrong wrote:
Add 'perf kvm-events' support to analyze kvm vmexit/mmio/ioport smartly
example output?
You can find a example output at this website:
http://lwn.net/Articles/479069/
[ Sorry, i did not put
Avi, Marcelo,
here is an updated version of patch 3 taking care of Carstens finding.
It also handles invalid target cpus more gracefully. Tested and
lockdep-approved.
Jens Freimann (1):
kvm-s390: make sigp restart return busy when stop pending
arch/s390/kvm/sigp.c | 31
From: Jens Freimann jf...@linux.vnet.ibm.com
On reboot the guest sends in smp_send_stop() a sigp stop to all CPUs
except for current CPU. Then the guest switches to the IPL cpu by
sending a restart to the IPL CPU, followed by a sigp stop to the
current cpu. Since restart is handled by userspace
On 02/07/2012 03:08 AM, Alexander Graf wrote:
I don't like the idea too much. On s390 and ppc we can set other vcpu's
interrupt status. How would that work in this model?
It would be a vm-wide syscall. You can also do that on x86 (through
KVM_IRQ_LINE).
I really do like the ioctl model
On 07.02.2012, at 13:24, Avi Kivity wrote:
On 02/07/2012 03:08 AM, Alexander Graf wrote:
I don't like the idea too much. On s390 and ppc we can set other vcpu's
interrupt status. How would that work in this model?
It would be a vm-wide syscall. You can also do that on x86 (through
On 02/07/2012 03:40 PM, Alexander Graf wrote:
Not sure we'll ever get there. For PPC, it will probably take another 1-2
years until we get the 32-bit targets stabilized. By then we will have new 64-bit
support though. And then the next gen will come out giving us even more new
constraints.
On 07.02.2012, at 15:21, Avi Kivity wrote:
On 02/07/2012 03:40 PM, Alexander Graf wrote:
Not sure we'll ever get there. For PPC, it will probably take another
1-2 years until we get the 32-bit targets stabilized. By then we will
have new 64-bit support though. And then the next gen
On 02/07/2012 07:40 AM, Alexander Graf wrote:
Why? For the HPET timer register for example, we could have a simple MMIO hook
that says
on_read:
return read_current_time() - shared_page.offset;
on_write:
handle_in_user_space();
For IDE, it would be as simple as
93 matches
Mail list logo
