On Mon, Jul 25, 2011 at 1:40 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Mon, Jul 25, 2011 at 5:25 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote:
On Fri, Jul 22, 2011 at 6:54 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Fri, Jul 22, 2011 at 10:20 AM, Zhi Yong Wu wu...@linux.vnet.ibm.com
On Fri, Jul 22, 2011 at 6:54 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Fri, Jul 22, 2011 at 10:20 AM, Zhi Yong Wu wu...@linux.vnet.ibm.com
wrote:
+static void bdrv_block_timer(void *opaque)
+{
+ BlockDriverState *bs = opaque;
+ BlockQueue *queue = bs-block_queue;
+ uint64_t
From: Jan Kiszka jan.kis...@siemens.com
kvm_add/remove_ioport_region need to know if the change is done during
init or while the system is running. We added qemu_system_is_ready for
this purpose which exported qemu_system_ready. The latter will be gone
soon, but we can also obtain the information
Hi Anthony,
On Mon, Jul 25, 2011 at 4:19 AM, Anthony Liguori anth...@codemonkey.ws wrote:
lguest already does this and lives in the kernel.
Does Lguest have SMP, usermode networking, and GUI support?
On Mon, Jul 25, 2011 at 4:19 AM, Anthony Liguori anth...@codemonkey.ws wrote:
So purely from
On 07/25/2011 10:27 AM, Pekka Enberg wrote:
Hi Anthony,
On Mon, Jul 25, 2011 at 4:19 AM, Anthony Liguorianth...@codemonkey.ws wrote:
lguest already does this and lives in the kernel.
Does Lguest have SMP, usermode networking, and GUI support?
IIRC, yes, no, and no.
On Mon, Jul 25, 2011
Hi Jan,
On Mon, Jul 25, 2011 at 2:12 AM, Jan Kiszka jan.kis...@web.de wrote:
I've read several times now that developing in a single tree leads to
better results. Can you provide some example from the QEMU/KVM projects
where the split is preventing innovation, optimizations, or some other
Hi Avi,
On Mon, Jul 25, 2011 at 10:36 AM, Avi Kivity a...@redhat.com wrote:
Are you talking about Documentation/lguest/lguest.c? How would you
suggest we unify our code with that?
It should be easy to have tools/kvm drive lguest - they're both virtio
based. All you need to do is provide yet
On Mon, 2011-07-25 at 01:12 +0200, Jan Kiszka wrote:
On 2011-07-24 22:37, Pekka Enberg wrote:
Hi Linus,
Please consider pulling from
ssh://master.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git
kvm-tool-for-linus
to merge the Native Linux KVM tool to Linux 3.1.
[
* Pekka Enberg penb...@kernel.org wrote:
On Mon, Jul 25, 2011 at 2:12 AM, Jan Kiszka jan.kis...@web.de wrote:
That said, I definitely appreciate the bug fixes as well as code and
documentation improvements for KVM that originate from this effort! I'm
just not convinced that writing a new
On Mon, 2011-07-25 at 10:36 +0300, Avi Kivity wrote:
On 07/25/2011 10:27 AM, Pekka Enberg wrote:
Hi Anthony,
On Mon, Jul 25, 2011 at 4:19 AM, Anthony Liguorianth...@codemonkey.ws
wrote:
lguest already does this and lives in the kernel.
Does Lguest have SMP, usermode networking,
On Mon, Jul 25, 2011 at 08:42:00AM +0800, Herbert Xu wrote:
Shirley Ma mashi...@us.ibm.com wrote:
This patch clears tx zero-copy flag as needed.
Sign-off-by: Shirley Ma x...@us.ibm.com
I think we also need to copy and clear this flag on the splice
read path as that takes a direct
Am 24.07.2011 21:45, schrieb Pekka Enberg:
This patch adds support for writing to zero refcount clusters. Refcount blocks
are cached in like L2 tables and flushed upon VIRTIO_BLK_T_FLUSH and when
evicted from the LRU cache.
With this patch applied, 'qemu-img check' no longer complains about
* Asias He asias.he...@gmail.com wrote:
On Mon, Jul 25, 2011 at 3:36 PM, Avi Kivity a...@redhat.com wrote:
On 07/25/2011 10:27 AM, Pekka Enberg wrote:
Hi Anthony,
On Mon, Jul 25, 2011 at 4:19 AM, Anthony Liguorianth...@codemonkey.ws
wrote:
lguest already does this and lives
On 25.07.2011, at 09:53, Ingo Molnar wrote:
* Pekka Enberg penb...@kernel.org wrote:
On Mon, Jul 25, 2011 at 2:12 AM, Jan Kiszka jan.kis...@web.de wrote:
That said, I definitely appreciate the bug fixes as well as code and
documentation improvements for KVM that originate from this
On Mon, Jul 25, 2011 at 4:19 AM, Anthony Liguorianth...@codemonkey.ws wrote:
lguest already does this and lives in the kernel.
On 07/25/2011 10:27 AM, Pekka Enberg wrote:
Does Lguest have SMP, usermode networking, and GUI support?
On Mon, Jul 25, 2011 at 3:36 PM, Avi Kivity a...@redhat.com
Hi Alexander,
On Mon, Jul 25, 2011 at 11:14 AM, Alexander Graf ag...@suse.de wrote:
Same here - in fact i first asked Qemu to be put into tools/qemu/ so
that it all becomes more hackable and more usable - that suggestion
was rebuked very strongly.
So instead of thinking a bit and trying to
Hi Alexander,
On Mon, Jul 25, 2011 at 11:14 AM, Alexander Graf ag...@suse.de wrote:
So i wanted to have a lightweight tool that allows me to test KVM and
tools/kvm/ does that very nicely: i type './kvm run' and i can test a
native bzImage (which has some virtualization options enabled as
On 25.07.2011, at 10:23, Pekka Enberg wrote:
Hi Alexander,
On Mon, Jul 25, 2011 at 11:14 AM, Alexander Graf ag...@suse.de wrote:
Same here - in fact i first asked Qemu to be put into tools/qemu/ so
that it all becomes more hackable and more usable - that suggestion
was rebuked very
On 25.07.2011, at 09:50, Sasha Levin wrote:
On Mon, 2011-07-25 at 01:12 +0200, Jan Kiszka wrote:
On 2011-07-24 22:37, Pekka Enberg wrote:
Hi Linus,
Please consider pulling from
ssh://master.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git
kvm-tool-for-linus
to merge the Native
On 07/25/2011 11:31 AM, Alexander Graf wrote:
In Ingo's reasoning, the next step would be to rewrite glibc and put it into
the kernel tree, because we end up adding syscalls so adding them to the
in-kernel libc with the same commit would be a lot easier and cleaner.
That actually makes a ton
Hi Alexander,
On Mon, Jul 25, 2011 at 11:31 AM, Alexander Graf ag...@suse.de wrote:
Damn you Ingo Molnar, I knew you'd somehow get all the credit for our
hard work! ;-)
Well, IIUC he's the one initiating the whole thing, no?
As much as I appreciate Ingo's help and support with the project,
On 25.07.2011, at 10:30, Pekka Enberg wrote:
Hi Alexander,
On Mon, Jul 25, 2011 at 11:14 AM, Alexander Graf ag...@suse.de wrote:
So i wanted to have a lightweight tool that allows me to test KVM and
tools/kvm/ does that very nicely: i type './kvm run' and i can test a
native bzImage
On Mon, Jul 25, 2011 at 11:07:43AM +0300, Michael S. Tsirkin wrote:
However macvtap passes an skb directly to the
lower device, so as long as macvtap is the only user
of that interface, we are fine I think - there's
no way for an skb to get from macvtap to splice
read path I think.
Right?
On 25.07.2011, at 10:37, Pekka Enberg wrote:
Hi Alexander,
On Mon, Jul 25, 2011 at 11:31 AM, Alexander Graf ag...@suse.de wrote:
Damn you Ingo Molnar, I knew you'd somehow get all the credit for our
hard work! ;-)
Well, IIUC he's the one initiating the whole thing, no?
As much as I
Hi Alexander,
On Mon, Jul 25, 2011 at 11:37 AM, Alexander Graf ag...@suse.de wrote:
different direction we're taking. Hell, we even went ahead and wrote our own
mini-BIOS just to keep things in one unified tree. ]
Yes, making sure that you have even more non-working non-Linux OSs.
You
qemu_malloc() is type-unsafe as it returns a void pointer. Introduce
QEMU_NEW() (and QEMU_NEWZ()), which return the correct type.
Signed-off-by: Avi Kivity a...@redhat.com
---
This is part of my memory API patchset, but doesn't really belong there.
qemu-common.h |3 +++
1 files changed, 3
On Mon, Jul 25, 2011 at 11:44 AM, Alexander Graf ag...@suse.de wrote:
For the same reasons we want tools/perf to be there.
Yeah, I want a pony too.
I can contact the Linux Foundation to see if we can arrange that.
Seriously, though, I don't understand your point. What is it? Do you
not agree
* Alexander Graf ag...@suse.de wrote:
On 25.07.2011, at 09:53, Ingo Molnar wrote:
* Pekka Enberg penb...@kernel.org wrote:
On Mon, Jul 25, 2011 at 2:12 AM, Jan Kiszka jan.kis...@web.de wrote:
That said, I definitely appreciate the bug fixes as well as
code and documentation
On 25.07.2011, at 10:51, Pekka Enberg wrote:
On Mon, Jul 25, 2011 at 11:44 AM, Alexander Graf ag...@suse.de wrote:
For the same reasons we want tools/perf to be there.
Yeah, I want a pony too.
I can contact the Linux Foundation to see if we can arrange that.
Seriously, though, I don't
* Ingo Molnar mi...@elte.hu wrote:
Virtualization is very tightly bound to the kernel, like it or not.
So is profiling, power management and a few other things.
And when you do 'ls tools/' you'll see exactly those topics
populated:
earth5:~/tip ls tools/
firewire kvm perf power
On 25.07.2011, at 10:54, Ingo Molnar wrote:
* Alexander Graf ag...@suse.de wrote:
On 25.07.2011, at 09:53, Ingo Molnar wrote:
* Pekka Enberg penb...@kernel.org wrote:
On Mon, Jul 25, 2011 at 2:12 AM, Jan Kiszka jan.kis...@web.de wrote:
That said, I definitely appreciate the bug
On 25.07.2011, at 10:47, Pekka Enberg wrote:
Hi Alexander,
On Mon, Jul 25, 2011 at 11:37 AM, Alexander Graf ag...@suse.de wrote:
different direction we're taking. Hell, we even went ahead and wrote our
own
mini-BIOS just to keep things in one unified tree. ]
Yes, making sure that
* Pekka Enberg penb...@kernel.org wrote:
Hi Alexander,
On Mon, Jul 25, 2011 at 11:14 AM, Alexander Graf ag...@suse.de wrote:
Same here - in fact i first asked Qemu to be put into
tools/qemu/ so that it all becomes more hackable and more usable
- that suggestion was rebuked very
* Pekka Enberg penb...@kernel.org wrote:
Hi Alexander,
On Mon, Jul 25, 2011 at 11:31 AM, Alexander Graf ag...@suse.de wrote:
Damn you Ingo Molnar, I knew you'd somehow get all the credit for our
hard work! ;-)
Well, IIUC he's the one initiating the whole thing, no?
As much as I
* Pekka Enberg penb...@kernel.org wrote:
[ I thought the 'native Linux' part in 'native Linux KVM tool' was
a dead giveaway, really. ]
Now if people want to support other operating systems, that's cool
and I'm happy to help out where I can. But I don't understand why
people keep
On 25.07.2011, at 10:51, Avi Kivity wrote:
qemu_malloc() is type-unsafe as it returns a void pointer. Introduce
QEMU_NEW() (and QEMU_NEWZ()), which return the correct type.
What does this buy you over
type *x = qemu_malloc(sizeof(type));
? I find the non-C++ version easier to read even.
On Mon, 2011-07-25 at 11:32 +0200, Alexander Graf wrote:
On 25.07.2011, at 10:51, Avi Kivity wrote:
qemu_malloc() is type-unsafe as it returns a void pointer. Introduce
QEMU_NEW() (and QEMU_NEWZ()), which return the correct type.
What does this buy you over
type *x =
On 25.07.2011, at 11:26, Ingo Molnar wrote:
* Pekka Enberg penb...@kernel.org wrote:
[ I thought the 'native Linux' part in 'native Linux KVM tool' was
a dead giveaway, really. ]
Now if people want to support other operating systems, that's cool
and I'm happy to help out where I
* Alexander Graf ag...@suse.de wrote:
On 25.07.2011, at 10:54, Ingo Molnar wrote:
* Alexander Graf ag...@suse.de wrote:
On 25.07.2011, at 09:53, Ingo Molnar wrote:
* Pekka Enberg penb...@kernel.org wrote:
On Mon, Jul 25, 2011 at 2:12 AM, Jan Kiszka jan.kis...@web.de
On 25.07.2011, at 11:37, Sasha Levin wrote:
On Mon, 2011-07-25 at 11:32 +0200, Alexander Graf wrote:
On 25.07.2011, at 10:51, Avi Kivity wrote:
qemu_malloc() is type-unsafe as it returns a void pointer. Introduce
QEMU_NEW() (and QEMU_NEWZ()), which return the correct type.
What does
On Mon, Jul 25, 2011 at 04:40:57PM +0800, Herbert Xu wrote:
On Mon, Jul 25, 2011 at 11:07:43AM +0300, Michael S. Tsirkin wrote:
However macvtap passes an skb directly to the
lower device, so as long as macvtap is the only user
of that interface, we are fine I think - there's
no way for
On 25.07.2011, at 11:41, Ingo Molnar wrote:
Virtualization is very tightly bound to the kernel, like it or
not. So is profiling, power management and a few other things.
It's a very simple point and observation: tools which integrate to
the kernel so that they wouldnt even run on another
On 25 July 2011 10:32, Alexander Graf ag...@suse.de wrote:
On 25.07.2011, at 10:51, Avi Kivity wrote:
qemu_malloc() is type-unsafe as it returns a void pointer. Introduce
QEMU_NEW() (and QEMU_NEWZ()), which return the correct type.
What does this buy you over
type *x =
On 07/25/2011 12:41 PM, Ingo Molnar wrote:
Look at tools/kvm/ - i cannot do anything useful without a Linux
kernel under it. It's as deeply bound to the Linux kernel as it gets.
The actual code that interacts with the kernel is pretty small, and will
grow smaller (as a fraction) in time.
On 07/25/2011 12:43 PM, Alexander Graf wrote:
Hm - is there any way to get this without adding upper case C++'ish macros?
Switch to C++.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
On 07/25/2011 12:48 PM, Peter Maydell wrote:
On 25 July 2011 10:32, Alexander Grafag...@suse.de wrote:
On 25.07.2011, at 10:51, Avi Kivity wrote:
qemu_malloc() is type-unsafe as it returns a void pointer. Introduce
QEMU_NEW() (and QEMU_NEWZ()), which return the correct type.
What does
On 25.07.2011, at 11:52, Avi Kivity wrote:
On 07/25/2011 12:48 PM, Peter Maydell wrote:
On 25 July 2011 10:32, Alexander Grafag...@suse.de wrote:
On 25.07.2011, at 10:51, Avi Kivity wrote:
qemu_malloc() is type-unsafe as it returns a void pointer. Introduce
QEMU_NEW() (and
On Mon, Jul 25, 2011 at 12:44:14PM +0300, Michael S. Tsirkin wrote:
if yes that seems to always clone an skb, which in turn
does the copy so we are fine?
Yes you're right, it should be safe.
However, I think we should add a WARN_ON to the splice skb path
so that should a packet find its way
From: Herbert Xu herb...@gondor.hengli.com.au
Date: Mon, 25 Jul 2011 17:57:11 +0800
However, I think we should add a WARN_ON to the splice skb path
so that should a packet find its way through a path that we haven't
thought of then at least we'll know about it.
Good idea.
--
To unsubscribe
On 07/25/2011 12:56 PM, Alexander Graf wrote:
That argument can be used to block any change. You'll get used to it in
time. The question is, is the new interface better or not.
I agree that it keeps you from accidently malloc'ing a struct of pointer size.
But couldn't we also just add
* Avi Kivity a...@redhat.com wrote:
On 07/25/2011 12:41 PM, Ingo Molnar wrote:
Look at tools/kvm/ - i cannot do anything useful without a Linux
kernel under it. It's as deeply bound to the Linux kernel as it
gets.
The actual code that interacts with the kernel is pretty small, and
On 25.07.2011, at 12:02, Avi Kivity wrote:
On 07/25/2011 12:56 PM, Alexander Graf wrote:
That argument can be used to block any change. You'll get used to it in
time. The question is, is the new interface better or not.
I agree that it keeps you from accidently malloc'ing a struct
On Mon, Jul 25, 2011 at 9:51 AM, Avi Kivity a...@redhat.com wrote:
qemu_malloc() is type-unsafe as it returns a void pointer. Introduce
QEMU_NEW() (and QEMU_NEWZ()), which return the correct type.
Signed-off-by: Avi Kivity a...@redhat.com
---
This is part of my memory API patchset, but
On 07/25/2011 01:04 PM, Alexander Graf wrote:
On 25.07.2011, at 12:02, Avi Kivity wrote:
On 07/25/2011 12:56 PM, Alexander Graf wrote:
That argument can be used to block any change. You'll get used to it
in time. The question is, is the new interface better or not.
I agree that
On 07/25/2011 01:06 PM, Stefan Hajnoczi wrote:
char *qemu_strndup(const char *str, size_t size);
+#define QEMU_NEW(type) ((type *)(qemu_malloc(sizeof(type
+#define QEMU_NEWZ(type) ((type *)(qemu_mallocz(sizeof(type
Does this mean we need to duplicate the type name for each
* Alexander Graf ag...@suse.de wrote:
In fact one of the problems i see with Qemu is that Qemu had to
make many compromises to support Windows and other weird
platforms that i'm (and i'd claim most other Linux kernel
developers) are personally not interested in.
It's what makes it
On 07/25/2011 01:03 PM, Ingo Molnar wrote:
Then look at the actual drivers and interfaces within tools/kvm/.
It's using the same symbols and conventions for 'guest' and
'host' side.
Check out tools/kvm/hw/i8042.c and match it up with
include/linux/serio.h and
On 25.07.2011, at 12:09, Avi Kivity wrote:
On 07/25/2011 01:04 PM, Alexander Graf wrote:
On 25.07.2011, at 12:02, Avi Kivity wrote:
On 07/25/2011 12:56 PM, Alexander Graf wrote:
That argument can be used to block any change. You'll get used to
it in time. The question is,
On 25.07.2011, at 12:16, Ingo Molnar wrote:
So it was a no brainer for me to pull it into -tip.
The thing I don't agree with is that it should live in the kernel
tree.
FYI, tools/kvm/ *already* lives in the kernel tree - that is how it's
developed and used and it also shares code
* Alexander Graf ag...@suse.de wrote:
On 25.07.2011, at 11:41, Ingo Molnar wrote:
Virtualization is very tightly bound to the kernel, like it or
not. So is profiling, power management and a few other things.
It's a very simple point and observation: tools which integrate
to the
* Avi Kivity a...@redhat.com wrote:
On 07/25/2011 01:03 PM, Ingo Molnar wrote:
Then look at the actual drivers and interfaces within tools/kvm/.
It's using the same symbols and conventions for 'guest' and
'host' side.
Check out tools/kvm/hw/i8042.c and match it up with
* Alexander Graf ag...@suse.de wrote:
On 25.07.2011, at 12:16, Ingo Molnar wrote:
So it was a no brainer for me to pull it into -tip.
The thing I don't agree with is that it should live in the
kernel tree.
FYI, tools/kvm/ *already* lives in the kernel tree - that is how
On Mon, Jul 25, 2011 at 10:14:13AM +0200, Alexander Graf wrote:
So instead of thinking a bit and trying to realize that there might be a
reason people don't want all their user space in the kernel tree you go ahead
and start your own crusade of creating a new user space. Great. That's how I
On Mon, 25 Jul 2011, Alexander Graf wrote:
On 25.07.2011, at 12:09, Avi Kivity wrote:
On 07/25/2011 01:04 PM, Alexander Graf wrote:
On 25.07.2011, at 12:02, Avi Kivity wrote:
On 07/25/2011 12:56 PM, Alexander Graf wrote:
That argument can be used to block any change.
* Alexander Graf ag...@suse.de wrote:
You know, they said the same thing about oprofile. All you needed
to do was to write few simple shell scripts to make it work. One
of the key features of tools/kvm is 'as little configuration as
possible' and I can assure you that bash alias is
On Mon, Jul 25, 2011 at 03:02:29AM -0700, David Miller wrote:
From: Herbert Xu herb...@gondor.hengli.com.au
Date: Mon, 25 Jul 2011 17:57:11 +0800
However, I think we should add a WARN_ON to the splice skb path
so that should a packet find its way through a path that we haven't
thought of
Avi Kivity a...@redhat.com writes:
On 07/25/2011 01:04 PM, Alexander Graf wrote:
On 25.07.2011, at 12:02, Avi Kivity wrote:
On 07/25/2011 12:56 PM, Alexander Graf wrote:
That argument can be used to block any change. You'll get used to
it in time. The question is, is the new
Kevin Wolf kw...@redhat.com writes:
Am 25.07.2011 12:06, schrieb Stefan Hajnoczi:
On Mon, Jul 25, 2011 at 9:51 AM, Avi Kivity a...@redhat.com wrote:
qemu_malloc() is type-unsafe as it returns a void pointer. Introduce
QEMU_NEW() (and QEMU_NEWZ()), which return the correct type.
* Christoph Hellwig h...@infradead.org wrote:
So, since we already have the lguest tool in the kernel tree,
why cannot we have the much more capable tools/kvm/ in the
tree?
Lguest is in Documentation/ for a reason. It's not meant as a
user space tool that you take as-is and
On 25.07.2011, at 12:59, Markus Armbruster wrote:
Avi Kivity a...@redhat.com writes:
On 07/25/2011 01:04 PM, Alexander Graf wrote:
On 25.07.2011, at 12:02, Avi Kivity wrote:
On 07/25/2011 12:56 PM, Alexander Graf wrote:
That argument can be used to block any change. You'll get used
On Mon, Jul 25, 2011 at 01:08:10PM +0200, Ingo Molnar wrote:
Fact is that developing ABIs within an integrated project is
*amazingly* powerful. You should try it one day, instead of
criticizing it :-)
I've been doing this long before you declare it the rosetta stone. Some
of the worst ABIs
* Christoph Hellwig h...@infradead.org wrote:
On Mon, Jul 25, 2011 at 01:08:10PM +0200, Ingo Molnar wrote:
Fact is that developing ABIs within an integrated project is
*amazingly* powerful. You should try it one day, instead of
criticizing it :-)
I've been doing this long before you
On Mon, Jul 25, 2011 at 07:24:12AM -0400, Christoph Hellwig wrote:
On Mon, Jul 25, 2011 at 01:08:10PM +0200, Ingo Molnar wrote:
Fact is that developing ABIs within an integrated project is
*amazingly* powerful. You should try it one day, instead of
criticizing it :-)
I've been doing
On 07/25/2011 12:32 PM, Alexander Graf wrote:
On 25.07.2011, at 10:51, Avi Kivity wrote:
qemu_malloc() is type-unsafe as it returns a void pointer. Introduce
QEMU_NEW() (and QEMU_NEWZ()), which return the correct type.
What does this buy you over
type *x = qemu_malloc(sizeof(type));
? I
On Mon, Jul 25, 2011 at 11:03:32AM +0200, Alexander Graf wrote:
It's very hard to understand. It's similar to religion - I could
easily apply your point to every reasonably low-level user space
project out there. X for example. X needs to interact with KMS and
DRI and whatdoiknow. So it'd be a
On Mon, Jul 25, 2011 at 01:34:25PM +0200, Olivier Galibert wrote:
You need someone with taste in the loop. But if you do, evolved is
always better than designed before you actually know what you need.
As I'm sure you perfectly know, for the matter.
Neither is actually helpful. You reall
On 07/25/2011 02:02 PM, Markus Armbruster wrote:
Side-stepping the stupid OMG malloc(0) is weird, therefore we must make
qemu_malloc(0) differently weird controversy would be useful all by
itself.
If we all work together, we can make this thread even bigger than the
tools/kvm pull request.
* Christoph Hellwig h...@infradead.org wrote:
On Mon, Jul 25, 2011 at 10:14:13AM +0200, Alexander Graf wrote:
So instead of thinking a bit and trying to realize that there
might be a reason people don't want all their user space in the
kernel tree you go ahead and start your own
On Wed, 2011-07-13 at 10:07 +0300, Avi Kivity wrote:
Second, introducing a new type of exit doesn't mean we see more exits.
Third, the new type of exit is probably not needed - we can use the
existing mmio/pio exits, and document that in certain cases the kernel
will fall back to these
On 07/25/2011 03:51 AM, Avi Kivity wrote:
qemu_malloc() is type-unsafe as it returns a void pointer. Introduce
QEMU_NEW() (and QEMU_NEWZ()), which return the correct type.
Just use g_new() and g_new0()
Regards,
Anthony Liguori
Signed-off-by: Avi Kivitya...@redhat.com
---
This is part of
On 07/25/2011 03:10 PM, Sasha Levin wrote:
On Wed, 2011-07-13 at 10:07 +0300, Avi Kivity wrote:
Second, introducing a new type of exit doesn't mean we see more exits.
Third, the new type of exit is probably not needed - we can use the
existing mmio/pio exits, and document that in certain
On 07/25/2011 03:11 PM, Anthony Liguori wrote:
On 07/25/2011 03:51 AM, Avi Kivity wrote:
qemu_malloc() is type-unsafe as it returns a void pointer. Introduce
QEMU_NEW() (and QEMU_NEWZ()), which return the correct type.
Just use g_new() and g_new0()
These bypass qemu_malloc(). Are we okay
On 07/25/2011 06:11 AM, Alexander Graf wrote:
#define QEMU_NEW_MULTI(type, len) ((type *)(qemu_mallocz(sizeof(type) * len)))
char *arr = QEMU_NEW_MULTI(char, 1024);
Still not covered: allocating a struct with a variable-size array as
final member. I guess a solution for that can be found if
On 07/25/2011 07:18 AM, Avi Kivity wrote:
On 07/25/2011 03:11 PM, Anthony Liguori wrote:
On 07/25/2011 03:51 AM, Avi Kivity wrote:
qemu_malloc() is type-unsafe as it returns a void pointer. Introduce
QEMU_NEW() (and QEMU_NEWZ()), which return the correct type.
Just use g_new() and g_new0()
Am 25.07.2011 10:30, schrieb Pekka Enberg:
Hi Alexander,
On Mon, Jul 25, 2011 at 11:14 AM, Alexander Graf ag...@suse.de wrote:
So i wanted to have a lightweight tool that allows me to test KVM and
tools/kvm/ does that very nicely: i type './kvm run' and i can test a
native bzImage (which
On Mon, Jul 25, 2011 at 8:08 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote:
On Fri, Jul 22, 2011 at 6:54 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Fri, Jul 22, 2011 at 10:20 AM, Zhi Yong Wu wu...@linux.vnet.ibm.com
wrote:
+ elapsed_time = (real_time - bs-slice_start[is_write]) /
On Mon, 2011-07-25 at 15:16 +0300, Avi Kivity wrote:
On 07/25/2011 03:10 PM, Sasha Levin wrote:
On Wed, 2011-07-13 at 10:07 +0300, Avi Kivity wrote:
Second, introducing a new type of exit doesn't mean we see more exits.
Third, the new type of exit is probably not needed - we can use
On 07/25/2011 04:52 AM, Avi Kivity wrote:
On 07/25/2011 12:48 PM, Peter Maydell wrote:
On 25 July 2011 10:32, Alexander Grafag...@suse.de wrote:
On 25.07.2011, at 10:51, Avi Kivity wrote:
qemu_malloc() is type-unsafe as it returns a void pointer. Introduce
QEMU_NEW() (and QEMU_NEWZ()), which
Hi Christoph,
On Mon, 2011-07-25 at 06:38 -0400, Christoph Hellwig wrote:
On Mon, Jul 25, 2011 at 10:14:13AM +0200, Alexander Graf wrote:
So instead of thinking a bit and trying to realize that there might be a
reason people don't want all their user space in the kernel tree you go
ahead
On 07/25/2011 03:21 PM, Anthony Liguori wrote:
On 07/25/2011 07:18 AM, Avi Kivity wrote:
On 07/25/2011 03:11 PM, Anthony Liguori wrote:
On 07/25/2011 03:51 AM, Avi Kivity wrote:
qemu_malloc() is type-unsafe as it returns a void pointer. Introduce
QEMU_NEW() (and QEMU_NEWZ()), which return the
Hi Kevin,
On Mon, 2011-07-25 at 14:24 +0200, Kevin Wolf wrote:
You've just chosen a different default. I'd argue that most users (i.e.
not developers of the tool or the kernel) actually want to run with a
disk image and graphics. You can type qemu-kvm harddisk.img and that's
it. This is
On Mon, Jul 25, 2011 at 12:06 PM, Alexander Graf ag...@suse.de wrote:
And don't get this the wrong way either, I'm not hostile against other
operating systems, but I simply am not interested enough in them to
spend my time improving them.
Then kvm-tool is about as useful as Mac-on-Linux. Why
On 07/25/2011 03:41 PM, Pekka Enberg wrote:
On Mon, 2011-07-25 at 14:24 +0200, Kevin Wolf wrote:
So, as always, which set of command line switches works better for you
depends entirely on your use case.
I actually don't agree. I think Qemu requires way too much configuration
from the user
On 07/25/2011 03:45 PM, Pekka Enberg wrote:
On Mon, Jul 25, 2011 at 12:06 PM, Alexander Grafag...@suse.de wrote:
And don't get this the wrong way either, I'm not hostile against other
operating systems, but I simply am not interested enough in them to
spend my time improving them.
Then
Since the -enable-nesting option is no longer available remove the
option from the config file.
Signed-off-by: Conny Seidel conny.sei...@amd.com
---
x86/unittests.cfg |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/x86/unittests.cfg b/x86/unittests.cfg
index
On 25.07.2011, at 14:47, Avi Kivity wrote:
On 07/25/2011 03:45 PM, Pekka Enberg wrote:
On Mon, Jul 25, 2011 at 12:06 PM, Alexander Grafag...@suse.de wrote:
And don't get this the wrong way either, I'm not hostile against other
operating systems, but I simply am not interested enough in
On Mon, 2011-07-25 at 15:47 +0300, Avi Kivity wrote:
On 07/25/2011 03:45 PM, Pekka Enberg wrote:
On Mon, Jul 25, 2011 at 12:06 PM, Alexander Grafag...@suse.de wrote:
And don't get this the wrong way either, I'm not hostile against other
operating systems, but I simply am not interested
On 25.07.2011, at 14:51, Sasha Levin wrote:
On Mon, 2011-07-25 at 15:47 +0300, Avi Kivity wrote:
On 07/25/2011 03:45 PM, Pekka Enberg wrote:
On Mon, Jul 25, 2011 at 12:06 PM, Alexander Grafag...@suse.de wrote:
And don't get this the wrong way either, I'm not hostile against other
operating
On 07/25/2011 09:50 AM, Sasha Levin wrote:
Anthony had a talk on last years KVM forum regarding the QEMU threading
model (slide:
http://www.linux-kvm.org/wiki/images/7/70/2010-forum-threading-qemu.pdf) .
It was suggested that the KVM part of QEMU is having a hard time
achieving the ideal
On 07/25/2011 03:26 PM, Sasha Levin wrote:
You can't block when a signal is pending. You can block, however, after
you've exited with -EINTR and re-entered.
What would happen with the MMIO then? I need to provide an answer before
I leave the read/write functions to exit with -EINTR, no?
1 - 100 of 228 matches
Mail list logo
