On Fri, Jul 22, 2011 at 6:54 PM, Stefan Hajnoczi wrote:
> On Fri, Jul 22, 2011 at 10:20 AM, Zhi Yong Wu
> wrote:
>> +static void bdrv_block_timer(void *opaque)
>> +{
>> + BlockDriverState *bs = opaque;
>> + BlockQueue *queue = bs->block_queue;
>> + uint64_t intval = 1;
>> +
>> + whil
From: Jan Kiszka
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 "hot-plug or not" from
Hi Anthony,
On Mon, Jul 25, 2011 at 4:19 AM, Anthony Liguori 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 wrote:
> So purely from a kernel perspective, why have two tools
On 07/25/2011 10:27 AM, Pekka Enberg wrote:
Hi Anthony,
On Mon, Jul 25, 2011 at 4:19 AM, Anthony Liguori 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 at 4:19 AM, Anthony
Hi Jan,
On Mon, Jul 25, 2011 at 2:12 AM, Jan Kiszka 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
> kind of progress?
Hi Avi,
On Mon, Jul 25, 2011 at 10:36 AM, Avi Kivity 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 another
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 Lin
* Pekka Enberg wrote:
> On Mon, Jul 25, 2011 at 2:12 AM, Jan Kiszka 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 userland and merging it into
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 Liguori
> > wrote:
> > > lguest already does this and lives in the kernel.
> >
> > Does Lguest have SMP, usermode networking, and GU
On Mon, Jul 25, 2011 at 08:42:00AM +0800, Herbert Xu wrote:
> Shirley Ma wrote:
> >
> > This patch clears tx zero-copy flag as needed.
> >
> > Sign-off-by: Shirley Ma
>
> I think we also need to copy and clear this flag on the splice
> read path as that takes a direct page reference.
>
> I ho
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 ab
* Asias He wrote:
> On Mon, Jul 25, 2011 at 3:36 PM, 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 Liguori
> >> wrote:
> >> > lguest already does this and lives in the kernel.
> >>
> >> Does Lguest
On 25.07.2011, at 09:53, Ingo Molnar wrote:
>
> * Pekka Enberg wrote:
>
>> On Mon, Jul 25, 2011 at 2:12 AM, Jan Kiszka 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 convi
On Mon, Jul 25, 2011 at 4:19 AM, Anthony Liguori 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 wrote:
>> > IIRC, yes, no,
Hi Alexander,
On Mon, Jul 25, 2011 at 11:14 AM, Alexander Graf 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 realize
Hi Alexander,
On Mon, Jul 25, 2011 at 11:14 AM, Alexander Graf 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
>> well) on t
On 25.07.2011, at 10:23, Pekka Enberg wrote:
> Hi Alexander,
>
> On Mon, Jul 25, 2011 at 11:14 AM, Alexander Graf 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
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
>>
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 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, no,
I don
On 25.07.2011, at 10:30, Pekka Enberg wrote:
> Hi Alexander,
>
> On Mon, Jul 25, 2011 at 11:14 AM, Alexander Graf 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 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.
>
>
On 25.07.2011, at 10:37, Pekka Enberg wrote:
> Hi Alexander,
>
> On Mon, Jul 25, 2011 at 11:31 AM, Alexander Graf 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 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 know, I've b
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
---
This is part of my memory API patchset, but doesn't really belong there.
qemu-common.h |3 +++
1 files changed, 3 insertions(+),
On Mon, Jul 25, 2011 at 11:44 AM, Alexander Graf 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 that perf
* Alexander Graf wrote:
> On 25.07.2011, at 09:53, Ingo Molnar wrote:
>
> >
> > * Pekka Enberg wrote:
> >
> >> On Mon, Jul 25, 2011 at 2:12 AM, Jan Kiszka wrote:
> >>>
> >>> That said, I definitely appreciate the bug fixes as well as
> >>> code and documentation improvements for KVM that o
On 25.07.2011, at 10:51, Pekka Enberg wrote:
> On Mon, Jul 25, 2011 at 11:44 AM, Alexander Graf 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 u
* 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.
>
> And when you do 'ls tools/' you'll see exactly those topics
> populated:
>
> earth5:~/tip> ls tools/
> firewire kvm perf power slub
On 25.07.2011, at 10:54, Ingo Molnar wrote:
>
> * Alexander Graf wrote:
>
>> On 25.07.2011, at 09:53, Ingo Molnar wrote:
>>
>>>
>>> * Pekka Enberg wrote:
>>>
On Mon, Jul 25, 2011 at 2:12 AM, Jan Kiszka wrote:
>
> That said, I definitely appreciate the bug fixes as well as
>
On 25.07.2011, at 10:47, Pekka Enberg wrote:
> Hi Alexander,
>
> On Mon, Jul 25, 2011 at 11:37 AM, Alexander Graf 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 wrote:
> Hi Alexander,
>
> On Mon, Jul 25, 2011 at 11:14 AM, Alexander Graf 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 ins
* Pekka Enberg wrote:
> Hi Alexander,
>
> On Mon, Jul 25, 2011 at 11:31 AM, Alexander Graf 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 h
* Pekka Enberg 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 bringing non-Linux
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 = qemu_ma
On 25.07.2011, at 11:26, Ingo Molnar wrote:
>
> * Pekka Enberg 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
* Alexander Graf wrote:
> On 25.07.2011, at 10:54, Ingo Molnar wrote:
>
> >
> > * Alexander Graf wrote:
> >
> >> On 25.07.2011, at 09:53, Ingo Molnar wrote:
> >>
> >>>
> >>> * Pekka Enberg wrote:
> >>>
> On Mon, Jul 25, 2011 at 2:12 AM, Jan Kiszka wrote:
> >
> > That said,
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.
>>
>
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
> > n
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
On 25 July 2011 10:32, 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))
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.
Th
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 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 b
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 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
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
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 from this list: send the lin
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 t
* Avi Kivity 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
> will
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'
On Mon, Jul 25, 2011 at 9: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.
>
> Signed-off-by: Avi Kivity
> ---
>
> This is part of my memory API patchset, but doesn't really belong there
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 a
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 a
* Alexander Graf 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 so p
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 dr
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
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 s
Am 25.07.2011 12:06, schrieb Stefan Hajnoczi:
> On Mon, Jul 25, 2011 at 9: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.
>>
>> Signed-off-by: Avi Kivity
>> ---
>>
>> This is part of
On Mon, Jul 25, 2011 at 11:25 AM, Kevin Wolf wrote:
> Am 25.07.2011 12:06, schrieb Stefan Hajnoczi:
>> On Mon, Jul 25, 2011 at 9: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.
>>>
* Alexander Graf 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 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 w
* Alexander Graf 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
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 u
* Alexander Graf 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 really n
On Mon, Jul 25, 2011 at 03:02:29AM -0700, David Miller wrote:
> From: Herbert Xu
> 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
Avi Kivity 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 th
Kevin Wolf writes:
> Am 25.07.2011 12:06, schrieb Stefan Hajnoczi:
>> On Mon, Jul 25, 2011 at 9: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.
>>>
>>> Signed-off-by: Avi Kivity
>
* Christoph Hellwig 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 use. I
On 25.07.2011, at 12:59, Markus Armbruster wrote:
> Avi Kivity 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
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 ABI
* 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 this long before you declare
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
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));
?
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 b
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 r
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 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 crusade of creatin
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 Kivity
---
This is part of my memory API p
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 certa
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 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
On Mon, Jul 25, 2011 at 8:08 AM, Zhi Yong Wu wrote:
> On Fri, Jul 22, 2011 at 6:54 PM, Stefan Hajnoczi wrote:
>> On Fri, Jul 22, 2011 at 10:20 AM, Zhi Yong Wu
>> wrote:
>>> + elapsed_time = (real_time - bs->slice_start[is_write]) / 10.0;
>>> + fprintf(stderr, "real_time = %ld, sl
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 -
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 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 t
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
> >
When running the kvm unit tests on machines where some of the dependent
32bit devel libs aren't available, (libboost-pthread-mt, for example)
the build fails. The patch doesn't change the default behavior - it
simply adds the possibility to disable the API tests.
Usage: ./configure --disable_api_
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 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 don't
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 Graf 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-t
Since the -enable-nesting option is no longer available remove the
option from the config file.
Signed-off-by: Conny Seidel
---
x86/unittests.cfg |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/x86/unittests.cfg b/x86/unittests.cfg
index 228ac1d..065020a 100644
--- a/x8
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 Graf 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 the
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 Graf wrote:
> > >> And don't get this the wrong way either, I'm not hostile against other
> > >> operating systems, but I simply am not interested en
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 Graf wrote:
> And don't get this the wrong way either, I'm not hostile against other
> operati
1 - 100 of 233 matches
Mail list logo
