* Ted Ts'o ty...@mit.edu wrote:
On Tue, Nov 08, 2011 at 01:55:09PM +0100, Ingo Molnar wrote:
I guess you can do well with a split project as well - my main
claim is that good compatibility comes *naturally* with
integration.
Here I have to disagree; my main worry is that integration
* Ted Ts'o ty...@mit.edu wrote:
On Tue, Nov 08, 2011 at 07:14:57PM +0200, Anca Emanuel wrote:
@Ten Ts'o: you are sponsored by something like microsoft (joking)
? Stop trolling. If you are not familiar with perf, or other
tools, save your time and do some useful things.
I am quite
* John Kacur jka...@redhat.com wrote:
On Tue, 8 Nov 2011, Ted Ts'o wrote:
On Tue, Nov 08, 2011 at 01:55:09PM +0100, Ingo Molnar wrote:
I guess you can do well with a split project as well - my main
claim is that good compatibility comes *naturally* with
integration.
Here I
On Tue, 2011-11-08 at 23:40 +0200, Michael S. Tsirkin wrote:
Here's a spec change documenting what my C patch does
(almost - I tweaked the layout a bit, but the idea is the same).
Some more cleanups are needed but I thought I'd send it
for early flames/comments.
The idea is simple: we split
* Gerd Hoffmann kra...@redhat.com wrote:
For reference, the default set of colors now is (from
tools/perf/util/ui/browser.c):
static struct ui_browser__colorset {
const char *name, *fg, *bg;
int colorset;
} ui_browser__colorsets[] = {
{
* Arnaldo Carvalho de Melo a...@redhat.com wrote:
sure the colors have enougth contrast so they are readable.
Problem is figuring out something that is considered a good default
:-\ There will always be somebody that will complain.
When doing the coding to allow using the default xterm
* Steven Rostedt rost...@goodmis.org wrote:
On Tue, Nov 08, 2011 at 10:32:25AM +0100, Ingo Molnar wrote:
None of the perf developers with whom i'm working complained
about the shared repo so far - publicly or privately. By all
means they are enjoying it and if you look at the stats
On Wed, Nov 9, 2011 at 2:06 AM, qemu-...@buildbot.b1-systems.de wrote:
The Buildbot has detected a new failure on builder default_x86_64_debian_5_0
while building qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/default_x86_64_debian_5_0/builds/1019
Hi!
As a follow-up to my previous post from Nov 8th,
OpenBSD 5.0 kernel panic in AMD K10 cpu power state
http://marc.info/?l=kvmm=132074436629761w=2
dmesg logs the following line everytime OpenBSD 5.0/i386
is booted as a guest:
kvm: cpu0 unhandled rdmsr: 0xc0010063
Hope that helps!
Regards,
On Tue, 2011-11-08 at 23:40 +0200, Michael S. Tsirkin wrote:
Here's a spec change documenting what my C patch does
(almost - I tweaked the layout a bit, but the idea is the same).
Some more cleanups are needed but I thought I'd send it
for early flames/comments.
The idea is simple: we split
On Wed, Nov 09, 2011 at 11:55:02AM +0200, Sasha Levin wrote:
On Tue, 2011-11-08 at 23:40 +0200, Michael S. Tsirkin wrote:
Here's a spec change documenting what my C patch does
(almost - I tweaked the layout a bit, but the idea is the same).
Some more cleanups are needed but I thought I'd
On Wed, Nov 09, 2011 at 10:46:06AM +0200, Sasha Levin wrote:
On Tue, 2011-11-08 at 23:40 +0200, Michael S. Tsirkin wrote:
Here's a spec change documenting what my C patch does
(almost - I tweaked the layout a bit, but the idea is the same).
Some more cleanups are needed but I thought I'd
On Wed, 2011-11-09 at 12:18 +0200, Michael S. Tsirkin wrote:
On Wed, Nov 09, 2011 at 11:55:02AM +0200, Sasha Levin wrote:
On Tue, 2011-11-08 at 23:40 +0200, Michael S. Tsirkin wrote:
Here's a spec change documenting what my C patch does
(almost - I tweaked the layout a bit, but the idea
On 11/08/2011 11:41 PM, Michael S. Tsirkin wrote:
PDF will follow.
Attached for the lyx challenged :)
The diagrams are truncated.
Otherwise looks reasonable.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
On Wed, 2011-11-09 at 12:13 +0200, Michael S. Tsirkin wrote:
On Wed, Nov 09, 2011 at 10:46:06AM +0200, Sasha Levin wrote:
The device initialization sequence might use an update as well.
What is needed? Add an item where the driver scans the PCI capability
list to detect the layout?
Yup,
On 11/08/2011 11:25 AM, Walter Haidinger wrote:
Hi!
OpenBSD 5.0/i386 throws a kernel panic when I try to
boot it inside a Linux KVM (host: vanilla 3.0.4,
openSUSE 11.4/x86_64) unter qemu-kvm 0.14.1 and 0.15.1.
Note that OpenBSD 4.9/i386 works.
The OpenBSD developers say:
the virtual
Hi,
What we want to have is to have a set of distinctive colors - just
two (background, foreground) colors are not enough - we also need
colors to highlight certain information - we need 5-6 colors for the
output to be maximally expressive. Is there a canonical way to handle
that while
On Wed, Nov 09, 2011 at 12:26:08PM +0200, Sasha Levin wrote:
On Wed, 2011-11-09 at 12:13 +0200, Michael S. Tsirkin wrote:
On Wed, Nov 09, 2011 at 10:46:06AM +0200, Sasha Levin wrote:
The device initialization sequence might use an update as well.
What is needed? Add an item where the
On Wed, 09 Nov 2011 11:40:01 +0100, Gerd Hoffmann wrote:
far I know it is pretty much impossible to figure the
foreground/background colors of the terminal you are running on. You
can try some guesswork based on $TERM (linux console usually has black
background, xterm is white by
On Wed, 2011-11-09 at 10:47 +, Pawel Moll wrote:
On Wed, 2011-11-09 at 10:20 +, Sasha Levin wrote:
I'm also wondering it it's ok to move virtio configuration out of virtio
space and into PCI space for archs that don't have PCI (such as ARM).
Just a note - ARM-based chips can by
On Wed, 2011-11-09 at 10:55 +, Sasha Levin wrote:
On Wed, 2011-11-09 at 10:47 +, Pawel Moll wrote:
Yep, it's actually already in 3.2-rc1 (drivers/virtio/virtio_mmio.c) and
in the spec (see Appendix X). And actually the control registers layout
I used was originally based on the PCI
On 9 November 2011 11:06, Pawel Moll pawel.m...@arm.com wrote:
On Wed, 2011-11-09 at 10:55 +, Sasha Levin wrote:
On Wed, 2011-11-09 at 10:47 +, Pawel Moll wrote:
Yep, it's actually already in 3.2-rc1 (drivers/virtio/virtio_mmio.c) and
in the spec (see Appendix X). And actually the
Em Wed, Nov 09, 2011 at 11:40:01AM +0100, Gerd Hoffmann escreveu:
Hi,
What we want to have is to have a set of distinctive colors - just
two (background, foreground) colors are not enough - we also need
colors to highlight certain information - we need 5-6 colors for the
output to
QCOW disk image async flag was erroneously enabled, while QCOW doesn't support
async ops yet.
This has caused a hang when booting QCOW images.
Reported-by: richard -rw- weinberger richard.weinber...@gmail.com
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/disk/qcow.c |2 +-
Em Wed, Nov 09, 2011 at 10:21:09AM +0100, Ingo Molnar escreveu:
Eventually someone will do the right thing and implement 'perf trace'
(there's still the tip:tmp.perf/trace2 prototype branch) and users
I'm working on it, reworking its patches into the new evlist/evsel
abstractions, etc.
-
On Wed, 2011-11-09 at 11:06 +, Pawel Moll wrote:
On Wed, 2011-11-09 at 10:55 +, Sasha Levin wrote:
On Wed, 2011-11-09 at 10:47 +, Pawel Moll wrote:
Yep, it's actually already in 3.2-rc1 (drivers/virtio/virtio_mmio.c) and
in the spec (see Appendix X). And actually the control
On Wed, 9 Nov 2011, Michael S. Tsirkin wrote:
KVM tool actually has support for 64bit features, we can probably remove
that when Pekka isn't looking :)
It's not yet released so maybe it's not an issue yet.
If it's too late I can re-add them to legacy too.
Pekka, 64 features aren't yet used
Hi,
Plus allowing full .perfconfig configurability of all the relevant
colors, for those with special taste.
Sure. Maybe also allow multiple color sections and pick them by $TERM
or --colors switch, i.e. [colors xterm].
Its fully configurable as of now, what we need is a set of
On Wed, 2011-11-09 at 14:25 +0200, Pekka Enberg wrote:
On Wed, 9 Nov 2011, Michael S. Tsirkin wrote:
KVM tool actually has support for 64bit features, we can probably remove
that when Pekka isn't looking :)
It's not yet released so maybe it's not an issue yet.
If it's too late I can
Em Wed, Nov 09, 2011 at 01:26:34PM +0100, Gerd Hoffmann escreveu:
Hi,
Plus allowing full .perfconfig configurability of all the relevant
colors, for those with special taste.
Sure. Maybe also allow multiple color sections and pick them by $TERM
or --colors switch, i.e. [colors
Em Wed, Nov 09, 2011 at 10:30:50AM -0200, Arnaldo Carvalho de Melo escreveu:
Em Wed, Nov 09, 2011 at 01:26:34PM +0100, Gerd Hoffmann escreveu:
Its fully configurable as of now, what we need is a set of .perfconfigs
that show how people think its better, we try it, set it as the default,
On Wed, 9 Nov 2011, Sasha Levin wrote:
They don't exist in kernel code either, for same reason as above.
Nothing will break if we remove it since no one really used it, we were
probably the first and only implementation of the spec which considered
them :)
As long as we are able to run older
On 11/09/2011 10:46 AM, Sasha Levin wrote:
Alternatively we can add new structures with new
structure IDs, pointed to from PCI configuration space.
As we don't yet have devices or drivers with 64 bit features,
I decided we don't need high feature bits in legacy space.
This also frees
On Wed, 2011-11-09 at 10:33 -0200, Arnaldo Carvalho de Melo wrote:
Ingo, would that G+ page be useful for that?
*groan*
Can we please keep things sane?
--
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, 2011-11-09 at 14:38 +0200, Avi Kivity wrote:
On 11/09/2011 10:46 AM, Sasha Levin wrote:
Alternatively we can add new structures with new
structure IDs, pointed to from PCI configuration space.
As we don't yet have devices or drivers with 64 bit features,
I decided we don't
Em Wed, Nov 09, 2011 at 01:46:42PM +0100, Peter Zijlstra escreveu:
On Wed, 2011-11-09 at 10:33 -0200, Arnaldo Carvalho de Melo wrote:
Ingo, would that G+ page be useful for that?
*groan*
Can we please keep things sane?
ROFL, I had to ask that :-P
- Arnaldo
--
To unsubscribe from
* Arnaldo Carvalho de Melo a...@redhat.com wrote:
Em Wed, Nov 09, 2011 at 10:30:50AM -0200, Arnaldo Carvalho de Melo escreveu:
Em Wed, Nov 09, 2011 at 01:26:34PM +0100, Gerd Hoffmann escreveu:
Its fully configurable as of now, what we need is a set of .perfconfigs
that show how people
On 11/09/2011 12:39 PM, Avi Kivity wrote:
More from m...@openbsd.org:
OpenBSD 5.0 (GENERIC) #43: Wed Aug 17 10:10:52 MDT 2011
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Phenom(tm) II X6 1100T Processor (AuthenticAMD 686-class,
512KB L2 cache)
On Tue, Nov 8, 2011 at 5:32 PM, Ingo Molnar mi...@elte.hu wrote:
So i think you should seriously consider moving your projects *into*
tools/ instead of trying to get other projects to move out ...
You should at least *try* the unified model before criticising it -
because currently you guys
The fact that a host cpu supports a feature doesn't mean that QEMU and KVM
will also support it, yet -cpuid host brings host features wholesale.
We need to whitelist each feature separately to make sure we support it.
This patch adds KVM whitelisting (by simply using KVM_GET_SUPPORTED_CPUID
Am 09.11.2011 14:40, schrieb Avi Kivity:
Actually, it looks like an OpenBSD bug. According to the AMD documentation:
The current P-state value can be read using the P-State Status
Register. The P-State Current Limit Register and the P-State Status
Register are read-only registers. Writes to
Hi!
Is there any way to have high resolution clock sources?
Currently the native kvm tool seems to support only jiffies:
$ cat
/sys/devices/system/clocksource/clocksource0/available_clocksource
jiffies
Using qemu-kvm with the same kernel/host I can use tsc, hpet, acpi_pm.
Thanks,
//richard
For some reason some of the defines were set to HAS_VIRTIO instead of HAS_AIO.
This broke raw blk device.
Reported-by: richard -rw- weinberger richard.weinber...@gmail.com
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/disk/raw.c |4 ++--
1 files changed, 2 insertions(+),
On Wed, 2011-11-09 at 16:27 +0200, Richard Weinberger wrote:
Hi!
Is there any way to have high resolution clock sources?
Currently the native kvm tool seems to support only jiffies:
$ cat
/sys/devices/system/clocksource/clocksource0/available_clocksource
jiffies
Using qemu-kvm with the
On Wed, Nov 09, 2011 at 02:48:58PM +0200, Sasha Levin wrote:
On Wed, 2011-11-09 at 14:38 +0200, Avi Kivity wrote:
On 11/09/2011 10:46 AM, Sasha Levin wrote:
Alternatively we can add new structures with new
structure IDs, pointed to from PCI configuration space.
As we don't yet
Hi,
I've created a Google+ page for QEMU[1]. You'll also notice a button on the
qemu.org wiki that links to the Google+ page.
I'll be posting release information to this page along with any QEMU news. If
you find qemu-devel too busy to follow, then following the G+ page might be a
good
On Wed, Nov 09, 2011 at 02:36:43PM +0200, Pekka Enberg wrote:
On Wed, 9 Nov 2011, Sasha Levin wrote:
They don't exist in kernel code either, for same reason as above.
Nothing will break if we remove it since no one really used it, we were
probably the first and only implementation of the
On Wed, 09 Nov 2011 16:49:51 +0200, Sasha Levin
levinsasha...@gmail.com wrote:
We'll do kvm_clock as well if you compile it in the kernel.
CONFIG_HIGH_RES_TIMERS is on both host and guest kernels enabled.
BTW: Why adds the kvm tool notsc to the guest's kernel command line?
I don't think that
On Wed, Nov 09, 2011 at 02:48:58PM +0200, Sasha Levin wrote:
I was unable to check if it was actually implemented in the drivers
because
http://git.kernel.org/?p=virt/kvm/kvm-guest-drivers-windows.git;a=summary is
not quite there (*cough*).
I found a mirror:
On Wed, 2011-11-09 at 17:42 +0200, Richard Weinberger wrote:
On Wed, 09 Nov 2011 16:49:51 +0200, Sasha Levin
levinsasha...@gmail.com wrote:
We'll do kvm_clock as well if you compile it in the kernel.
CONFIG_HIGH_RES_TIMERS is on both host and guest kernels enabled.
BTW: Why adds the kvm
On Wed, Nov 09, 2011 at 05:49:53PM +0200, Sasha Levin wrote:
On Wed, 2011-11-09 at 17:42 +0200, Richard Weinberger wrote:
On Wed, 09 Nov 2011 16:49:51 +0200, Sasha Levin
levinsasha...@gmail.com wrote:
We'll do kvm_clock as well if you compile it in the kernel.
CONFIG_HIGH_RES_TIMERS
We seriously miss having a logo.
El 09/11/2011, a las 15:24, Anthony Liguori escribió:
Hi,
I've created a Google+ page for QEMU[1]. You'll also notice a button on the
qemu.org wiki that links to the Google+ page.
I'll be posting release information to this page along with any QEMU
On Wed, Nov 09, 2011 at 08:00:06PM +0400, Cyrill Gorcunov wrote:
...
You'll need CONFIG_KVM_CLOCK.
I'm not actually sure how close our implementation is to having tsc
working so far, Cyrill knows more about that than me.
We dropped tsc while were debuggin timer interrupts and
On 11/09/2011 10:04 AM, Natalia Portillo wrote:
We seriously miss having a logo.
Yes, I'll announce something about that tomorrow ;-)
Regards,
Anthony Liguori
El 09/11/2011, a las 15:24, Anthony Liguori escribió:
Hi,
I've created a Google+ page for QEMU[1]. You'll also notice a button
Hi guys, here I am, reporting yet another issue with qemu. This time,
it's something that was first reported in January, and Juan proposed a
patch for it:
http://comments.gmane.org/gmane.comp.emulators.qemu/89009
[PATCH 4/5] Reopen files after migration
The symptom is, when running disk
On 11/09/2011 10:29 AM, Lucas Meneghel Rodrigues wrote:
Hi guys, here I am, reporting yet another issue with qemu. This time, it's
something that was first reported in January, and Juan proposed a patch for it:
http://comments.gmane.org/gmane.comp.emulators.qemu/89009
Migration with qcow2 is
On 11/09/2011 06:39 PM, Anthony Liguori wrote:
Migration with qcow2 is not a supported feature for 1.0. Migration is
only supported with raw images using coherent shared storage[1].
[1] NFS is only coherent with close-to-open which right now is not
good enough for migration.
Say what?
--
On 11/09/2011 11:14 AM, Rodrigo Campos wrote:
On Wed, Nov 09, 2011 at 09:24:37AM -0600, Anthony Liguori wrote:
Hi,
I've created a Google+ page for QEMU[1]. You'll also notice a
button on the qemu.org wiki that links to the Google+ page.
I'll be posting release information to this page along
On 11/09/2011 11:02 AM, Avi Kivity wrote:
On 11/09/2011 06:39 PM, Anthony Liguori wrote:
Migration with qcow2 is not a supported feature for 1.0. Migration is
only supported with raw images using coherent shared storage[1].
[1] NFS is only coherent with close-to-open which right now is not
On Wed, Nov 09, 2011 at 11:25:10AM -0600, Anthony Liguori wrote:
On 11/09/2011 11:14 AM, Rodrigo Campos wrote:
On Wed, Nov 09, 2011 at 09:24:37AM -0600, Anthony Liguori wrote:
Hi,
I've created a Google+ page for QEMU[1]. You'll also notice a
button on the qemu.org wiki that links to the
On 11/09/2011 07:44 AM, Avi Kivity wrote:
The fact that a host cpu supports a feature doesn't mean that QEMU and KVM
will also support it, yet -cpuid host brings host features wholesale.
We need to whitelist each feature separately to make sure we support it.
This patch adds KVM whitelisting
On 11/09/2011 07:56 PM, Anthony Liguori wrote:
On 11/09/2011 07:44 AM, Avi Kivity wrote:
The fact that a host cpu supports a feature doesn't mean that QEMU
and KVM
will also support it, yet -cpuid host brings host features wholesale.
We need to whitelist each feature separately to make sure
On Wed, 2011-11-09 at 02:11 -0600, Christian Benvenuti (benve) wrote:
I have not gone through the all patch yet, but here are
my first comments/questions about the code in vfio_main.c
(and pci/vfio_pci.c).
Thanks! Comments inline...
-Original Message-
From: Alex Williamson
On Wed, Nov 09, 2011 at 09:24:37AM -0600, Anthony Liguori wrote:
Hi,
I've created a Google+ page for QEMU[1]. You'll also notice a
button on the qemu.org wiki that links to the Google+ page.
I'll be posting release information to this page along with any QEMU
news. If you find
On Wed, 2011-11-09 at 20:00 +0200, Avi Kivity wrote:
On 11/09/2011 07:56 PM, Anthony Liguori wrote:
On 11/09/2011 07:44 AM, Avi Kivity wrote:
The fact that a host cpu supports a feature doesn't mean that QEMU
and KVM
will also support it, yet -cpuid host brings host features wholesale.
On Wed, 9 Nov 2011 20:00:06 +0400, Cyrill Gorcunov gorcu...@gmail.com
wrote:
On Wed, Nov 09, 2011 at 05:49:53PM +0200, Sasha Levin wrote:
On Wed, 2011-11-09 at 17:42 +0200, Richard Weinberger wrote:
On Wed, 09 Nov 2011 16:49:51 +0200, Sasha Levin
levinsasha...@gmail.com wrote:
We'll do
Since virtio-mmio was introduced in 3.2, virtio-pci isn't the only transport
layer between the kernel and virtio devices.
This patch adds an abstract virtio-transport layer which allows to easily
use different transports while making it transparent to the device.
This is the first step in adding
On Wed, Nov 9, 2011 at 9:03 PM, Sasha Levin levinsasha...@gmail.com wrote:
+struct virtio_trans {
+ void *virtio;
+ enum VIRTIO_TRANS_TYPE type;
+ struct virtio_trans_ops trans_ops;
+ struct virtio_ops virtio_ops;
+};
Why are the ops not
On Wed, 2011-11-09 at 20:56 +0200, Richard Weinberger wrote:
On Wed, 9 Nov 2011 20:00:06 +0400, Cyrill Gorcunov gorcu...@gmail.com
wrote:
On Wed, Nov 09, 2011 at 05:49:53PM +0200, Sasha Levin wrote:
On Wed, 2011-11-09 at 17:42 +0200, Richard Weinberger wrote:
On Wed, 09 Nov 2011 16:49:51
On Wed, Nov 09, 2011 at 09:13:54PM +0200, Pekka Enberg wrote:
...
Yup, notsc was used in the early days to avoid APIC emulation.
Anyone care to send a patch to drop it from master?
Pekka
Here we go
---
Subject: [PATCH] tools, kvm: Drop notsc no longer needed kernel
Arnaldo Carvalho de Melo wrote:
Em Wed, Nov 09, 2011 at 11:40:01AM +0100, Gerd Hoffmann escreveu:
Hi,
What we want to have is to have a set of distinctive colors - just
two (background, foreground) colors are not enough - we also need
colors to highlight certain information - we
On 11/09/2011 07:44 AM, Avi Kivity wrote:
The fact that a host cpu supports a feature doesn't mean that QEMU and KVM
will also support it, yet -cpuid host brings host features wholesale.
We need to whitelist each feature separately to make sure we support it.
This patch adds KVM whitelisting
Lucas Meneghel Rodrigues l...@redhat.com wrote:
Hi guys, here I am, reporting yet another issue with qemu. This time,
it's something that was first reported in January, and Juan proposed a
patch for it:
http://comments.gmane.org/gmane.comp.emulators.qemu/89009
[PATCH 4/5] Reopen files after
Anthony Liguori anth...@codemonkey.ws wrote:
On 11/09/2011 11:02 AM, Avi Kivity wrote:
On 11/09/2011 06:39 PM, Anthony Liguori wrote:
Migration with qcow2 is not a supported feature for 1.0. Migration is
only supported with raw images using coherent shared storage[1].
[1] NFS is only
Since virtio-mmio was introduced in 3.2, virtio-pci isn't the only transport
layer between the kernel and virtio devices.
This patch adds an abstract virtio-transport layer which allows to easily
use different transports while making it transparent to the device.
This is the first step in adding
Em Wed, Nov 09, 2011 at 02:25:09PM -0500, Jim Paris escreveu:
Arnaldo Carvalho de Melo wrote:
Em Wed, Nov 09, 2011 at 11:40:01AM +0100, Gerd Hoffmann escreveu:
As far I know it is pretty much impossible to figure the
foreground/background colors of the terminal you are running on. You
On Wed, Nov 09, 2011 at 11:35:54AM -0600, Anthony Liguori wrote:
On 11/09/2011 11:02 AM, Avi Kivity wrote:
On 11/09/2011 06:39 PM, Anthony Liguori wrote:
Migration with qcow2 is not a supported feature for 1.0. Migration is
only supported with raw images using coherent shared storage[1].
On 11/09/2011 02:18 PM, Michael S. Tsirkin wrote:
On Wed, Nov 09, 2011 at 11:35:54AM -0600, Anthony Liguori wrote:
On 11/09/2011 11:02 AM, Avi Kivity wrote:
On 11/09/2011 06:39 PM, Anthony Liguori wrote:
Migration with qcow2 is not a supported feature for 1.0. Migration is
only supported
On Wed, 2011-11-09 at 21:59 +0200, Michael S. Tsirkin wrote:
[snip]
+\begin_layout Enumerate
+Reset the device.
+ This is not required on initial start up.
+\end_layout
+
+\begin_layout Enumerate
+The ACKNOWLEDGE status bit is set: we have noticed the device.
+\end_layout
+
On Wed, Nov 09, 2011 at 10:24:47PM +0200, Sasha Levin wrote:
On Wed, 2011-11-09 at 21:59 +0200, Michael S. Tsirkin wrote:
[snip]
+\begin_layout Enumerate
+Reset the device.
+ This is not required on initial start up.
+\end_layout
+
+\begin_layout Enumerate
+The ACKNOWLEDGE
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 09, 2011 at 11:35:54AM -0600, Anthony Liguori wrote:
On 11/09/2011 11:02 AM, Avi Kivity wrote:
On 11/09/2011 06:39 PM, Anthony Liguori wrote:
Migration with qcow2 is not a supported feature for 1.0. Migration is
only supported with raw
On Wed, 2011-11-09 at 22:52 +0200, Michael S. Tsirkin wrote:
On Wed, Nov 09, 2011 at 10:24:47PM +0200, Sasha Levin wrote:
On Wed, 2011-11-09 at 21:59 +0200, Michael S. Tsirkin wrote:
[snip]
+\begin_layout Enumerate
+Reset the device.
+ This is not required on initial start up.
On Wed, Nov 09, 2011 at 02:22:02PM -0600, Anthony Liguori wrote:
On 11/09/2011 02:18 PM, Michael S. Tsirkin wrote:
On Wed, Nov 09, 2011 at 11:35:54AM -0600, Anthony Liguori wrote:
On 11/09/2011 11:02 AM, Avi Kivity wrote:
On 11/09/2011 06:39 PM, Anthony Liguori wrote:
Migration with qcow2
On 11/09/2011 03:00 PM, Michael S. Tsirkin wrote:
On Wed, Nov 09, 2011 at 02:22:02PM -0600, Anthony Liguori wrote:
On 11/09/2011 02:18 PM, Michael S. Tsirkin wrote:
On Wed, Nov 09, 2011 at 11:35:54AM -0600, Anthony Liguori wrote:
On 11/09/2011 11:02 AM, Avi Kivity wrote:
On 11/09/2011 06:39
On Wed, Nov 09, 2011 at 10:57:28PM +0200, Sasha Levin wrote:
On Wed, 2011-11-09 at 22:52 +0200, Michael S. Tsirkin wrote:
On Wed, Nov 09, 2011 at 10:24:47PM +0200, Sasha Levin wrote:
On Wed, 2011-11-09 at 21:59 +0200, Michael S. Tsirkin wrote:
[snip]
+\begin_layout Enumerate
On Wed, 2011-11-09 at 23:14 +0200, Michael S. Tsirkin wrote:
On Wed, Nov 09, 2011 at 10:57:28PM +0200, Sasha Levin wrote:
On Wed, 2011-11-09 at 22:52 +0200, Michael S. Tsirkin wrote:
On Wed, Nov 09, 2011 at 10:24:47PM +0200, Sasha Levin wrote:
On Wed, 2011-11-09 at 21:59 +0200, Michael
I'd even argue that that C library is obviously something the
kernelshould offer as well - so klibc is the way to go and would help
usfurther streamline this and keep Linux quality high.
I think there is code to share. Why not ?
--
To unsubscribe from this list: send the line unsubscribe kvm in
On 11/09/2011 05:25 PM, Juan Quintela wrote:
Lucas Meneghel Rodriguesl...@redhat.com wrote:
Hi guys, here I am, reporting yet another issue with qemu. This time,
it's something that was first reported in January, and Juan proposed a
patch for it:
On Wed, 2011-11-09 at 15:08 -0600, Christian Benvenuti (benve) wrote:
snip
+
+struct vfio_group {
+ dev_t devt;
+ unsigned intgroupid;
This groupid is returned by the device_group callback you recently
added
with a separate (not
The CONFIG_E500 config option is ambiguous and used incorrectly in many
places to refer to some combination of e500v1/v2, e500mc, and e5500.
Fix up each reference to use the correct combinations of the following
config options:
CONFIG_FSL_E500_V1_V2
CONFIG_FSL_E500MC
CONFIG_FSL_E5500
Here are few minor comments on vfio_iommu.c ...
diff --git a/drivers/vfio/vfio_iommu.c b/drivers/vfio/vfio_iommu.c
new file mode 100644
index 000..029dae3
--- /dev/null
+++ b/drivers/vfio/vfio_iommu.c
@@ -0,0 +1,530 @@
+/*
+ * VFIO: IOMMU DMA mapping support
+ *
+ * Copyright (C)
On 09.11.2011, at 09:23, Ingo Molnar wrote:
* Ted Ts'o ty...@mit.edu wrote:
On Tue, Nov 08, 2011 at 01:55:09PM +0100, Ingo Molnar wrote:
I guess you can do well with a split project as well - my main
claim is that good compatibility comes *naturally* with
integration.
Here I have
On 11/04/2011 03:38 AM, Pekka Enberg wrote:
Hi Linus,
Please consider pulling the latest KVM tool tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git
kvmtool/for-linus
[snip]
tools/kvm/virtio/net.c | 423
tools/kvm/virtio/pci.c | 319 ++
-int iommu_unmap(struct iommu_domain *domain, unsigned long iova, int
gfp_order)
+size_t iommu_unmap(struct iommu_domain *domain, unsigned long iova, size_t
size)
{
- size_t size, unmapped;
+ size_t unmapped_page, unmapped = 0;
+ unsigned int min_pagesz;
if
Hi Anthony,
On 11/04/2011 03:38 AM, Pekka Enberg wrote:
Hi Linus,
Please consider pulling the latest KVM tool tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git
kvmtool/for-linus
[snip]
tools/kvm/virtio/net.c | 423
tools/kvm/virtio/pci.c | 319 ++
On Thu, Nov 10, 2011 at 8:17 AM, Kai Huang mail.kai.hu...@gmail.com wrote:
Seems the unmap function don't take phys as parameter, does this mean
domain-ops-unmap will walk through the page table to find out the
actual page size?
The short answer is yes, and furthermore, we also consider to
* Américo Wang xiyou.wangc...@gmail.com wrote:
On Tue, Nov 8, 2011 at 5:32 PM, Ingo Molnar mi...@elte.hu wrote:
So i think you should seriously consider moving your projects
*into* tools/ instead of trying to get other projects to move out
...
You should at least *try* the unified
Pekka Enberg penb...@kernel.org writes:
Hi Anthony,
On 11/04/2011 03:38 AM, Pekka Enberg wrote:
Hi Linus,
Please consider pulling the latest KVM tool tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git
kvmtool/for-linus
[snip]
tools/kvm/virtio/net.c | 423
The CONFIG_E500 config option is ambiguous and used incorrectly in many
places to refer to some combination of e500v1/v2, e500mc, and e5500.
Fix up each reference to use the correct combinations of the following
config options:
CONFIG_FSL_E500_V1_V2
CONFIG_FSL_E500MC
CONFIG_FSL_E5500
99 matches
Mail list logo
