On 2014-06-13 02:47, Rusty Russell wrote:
> Jan Kiszka writes:
>> On 2014-06-12 04:27, Rusty Russell wrote:
>>> Henning Schild writes:
>>> It was also never implemented, and remains a thought experiment.
>>> However, implementing it in lguest should be fairly easy.
>>
>> The reason why a trusted
On 06/12/2014 06:06 PM, Rusty Russell wrote:
> "H. Peter Anvin" writes:
>> I have gotten scattered reports of strange problems caused by the fact
>> that virtio_console doesn't behave like a normal tty (support termios
>> and so on.) This seems to be an odd restriction -- is there any
>> fundamen
"H. Peter Anvin" writes:
> I have gotten scattered reports of strange problems caused by the fact
> that virtio_console doesn't behave like a normal tty (support termios
> and so on.) This seems to be an odd restriction -- is there any
> fundamental reason for this design choice?
Not that I know
Jan Kiszka writes:
> On 2014-06-12 04:27, Rusty Russell wrote:
>> Henning Schild writes:
>> It was also never implemented, and remains a thought experiment.
>> However, implementing it in lguest should be fairly easy.
>
> The reason why a trusted helper, i.e. additional logic in the
> hypervisor,
On 06/12/2014 01:50 AM, Peter Zijlstra wrote:
On Wed, Jun 11, 2014 at 09:37:55PM -0400, Long, Wai Man wrote:
On 6/11/2014 6:54 AM, Peter Zijlstra wrote:
On Fri, May 30, 2014 at 11:43:55AM -0400, Waiman Long wrote:
Enabling this configuration feature causes a slight decrease the
performance of
On 06/12/2014 02:00 AM, Peter Zijlstra wrote:
On Wed, Jun 11, 2014 at 05:22:28PM -0400, Long, Wai Man wrote:
@@ -233,11 +233,25 @@ void queue_spin_lock_slowpath(struct qspinlock *lock, u32
val)
*/
for (;;) {
/*
-* If we observe any contention; q
On 06/12/2014 04:17 AM, Peter Zijlstra wrote:
On Fri, May 30, 2014 at 11:44:00AM -0400, Waiman Long wrote:
@@ -19,13 +19,46 @@ extern struct static_key virt_unfairlocks_enabled;
* that the clearing the lock bit is done ASAP without artificial delay
* due to compiler optimization.
*/
+#i
I have gotten scattered reports of strange problems caused by the fact
that virtio_console doesn't behave like a normal tty (support termios
and so on.) This seems to be an odd restriction -- is there any
fundamental reason for this design choice?
-hpa
__
On Thu, 2014-06-12 at 19:02 +0300, Michael S. Tsirkin wrote:
> Now that we have kvfree, use it in vhost-scsi instead of
> the open-coded version.
>
> Cc: Nicholas Bellinger
> Signed-off-by: Michael S. Tsirkin
> ---
>
> I have this queued for -rc2.
> Nicholas could you review ack pls?
Reviewed
Il 12/06/2014 18:02, Michael S. Tsirkin ha scritto:
Now that we have kvfree, use it in vhost-scsi instead of
the open-coded version.
Cc: Nicholas Bellinger
Signed-off-by: Michael S. Tsirkin
---
I have this queued for -rc2.
Nicholas could you review ack pls?
drivers/vhost/scsi.c | 12 ++-
Il 12/06/2014 18:02, Vincent JARDIN ha scritto:
* Get all the required parts outside QEMU packaged in major distros, or
absorbed into QEMU
Redhat did disable it. why? it is there in QEMU.
We don't ship everything that is part of QEMU, just like we selectively
disable many drivers in Lin
Markus,
see inline (I am not on all mailing list, please, keep the cc list).
> Sure! The reasons for my dislike range from practical to
> philosophical.
My practical concerns include:
1. ivshmem code needs work, but has no maintainer
See David's contributions:
http://patchwork.ozlabs.org/
Now that we have kvfree, use it in vhost-scsi instead of
the open-coded version.
Cc: Nicholas Bellinger
Signed-off-by: Michael S. Tsirkin
---
I have this queued for -rc2.
Nicholas could you review ack pls?
drivers/vhost/scsi.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-
Henning Schild writes:
> On Thu, 12 Jun 2014 08:48:04 +0200
> Markus Armbruster wrote:
>
>> Vincent JARDIN writes:
>>
>> > On 10/06/2014 18:48, Henning Schild wrote:> Hi,
>> >> In a first prototype i implemented a ivshmem[2] device for the
>> >> hypervisor. That way we can share memory between
Henning Schild writes:
> On Thu, 12 Jun 2014 08:48:04 +0200
> Markus Armbruster wrote:
>
>> Vincent JARDIN writes:
>>
>> > On 10/06/2014 18:48, Henning Schild wrote:> Hi,
>> >> In a first prototype i implemented a ivshmem[2] device for the
>> >> hypervisor. That way we can share memory between
On Thu, Jun 12, 2014 at 10:42:34AM +0200, Romain Francoise wrote:
> "Michael S. Tsirkin" writes:
>
> > Memory allocation for vhost-net now supports fallback on vmalloc (same
> > as for vhost-scsi) this makes it possible to create the device on
> > systems where memory is very fragmented, with sli
On 12/06/2014 09:44, Henning Schild wrote:
It may be used, but that doesn't mean it's maintained, or robust
>against abuse. My advice is to steer clear of it.
Could you elaborate on why you advice against it?
+1 elaborate please.
beside the DPDK source code, some other common use cases:
-
"Michael S. Tsirkin" writes:
> Memory allocation for vhost-net now supports fallback on vmalloc (same
> as for vhost-scsi) this makes it possible to create the device on
> systems where memory is very fragmented, with slightly lower
> performance.
Thanks Michael, I'm glad to see that this change
On Fri, May 30, 2014 at 11:44:00AM -0400, Waiman Long wrote:
> @@ -19,13 +19,46 @@ extern struct static_key virt_unfairlocks_enabled;
> * that the clearing the lock bit is done ASAP without artificial delay
> * due to compiler optimization.
> */
> +#ifdef CONFIG_PARAVIRT_SPINLOCKS
> +static _
On Thu, 12 Jun 2014 08:48:04 +0200
Markus Armbruster wrote:
> Vincent JARDIN writes:
>
> > On 10/06/2014 18:48, Henning Schild wrote:> Hi,
> >> In a first prototype i implemented a ivshmem[2] device for the
> >> hypervisor. That way we can share memory between virtual machines.
> >> Ivshmem is
20 matches
Mail list logo
