virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Sasha Levin <levinsasha928@gmail.com>
To: dlaor@redhat.com
Cc: wency@cn.fujitsu.com, kvm@vger.kernel.org, mst@redhat.com,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, penberg@kernel.org,
	avi@redhat.com, anthony@codemonkey.ws
Subject: Re: [RFC 0/2] virtio: provide a way for host to monitor critical events in the device
Date: Tue, 24 Jul 2012 15:01:59 +0200	[thread overview]
Message-ID: <500E9CC7.9020201@gmail.com> (raw)
In-Reply-To: <500E9942.3080505@redhat.com>

On 07/24/2012 02:46 PM, Dor Laor wrote:
> On 07/24/2012 03:30 PM, Sasha Levin wrote:
>> On 07/24/2012 10:26 AM, Dor Laor wrote:
>>> On 07/24/2012 07:55 AM, Rusty Russell wrote:
>>>> On Mon, 23 Jul 2012 22:32:39 +0200, Sasha Levin <levinsasha928@gmail.com> wrote:
>>>>> As it was discussed recently, there's currently no way for the guest to notify
>>>>> the host about panics. Further more, there's no reasonable way to notify the
>>>>> host of other critical events such as an OOM kill.
>>>>
>>>> I clearly missed the discussion.  Is this actually useful?  In practice,
>>>
>>> Admit this is not a killer feature..
>>>
>>>> won't you want the log from the guest?  What makes a virtual guest
>>>> different from a physical guest?
>>>
>>> Most times virt guest can do better than a physical OS. In that sense, this is where virtualization shines (live migration, hotplug for any virtual resource including net/block/cpu/memory/..).
>>>
>>> There are plenty of niche but worth while small features such as the virtio-trace series and other that allow the host/virt-mgmt to get more insight into the guest w/o a need to configure the guest.
>>>
>>> In theory guest OOM can trigger a host memory hot plug action. Again, I don't see it as a key feature..
>>>
>>>>
>>>> Guest watchdog functionality might be useful, but that's simpler to
>>>
>>> There is already a fully emulated watchdog device in qemu.
>>
>> There is, but why emulate physical devices when you can take advantage of virtio?
>>
>> You could say the same about the rest of the virtio family - "There is already a fully emulated NIC device in qemu".
> 
> The single issue virtio-nic solves is performance enhancements that can be done w/ a fully emulated NIC. The reason is that such NIC tend to access pio/mmio space a lot while virtio is designed for virtualization.

virtio on it's own was introduced to help solve the fragmentation around virtualized devices, so I don't think that the main purpose of doing virtio drivers is due to any performance benefits virtio may provide.

Also consider virtio devices which don't exactly have strict performance considerations such as virtio-9p or virtio-rng.

I mean, why implement virtio-rng when qemu could just emulate some sort of a hardware RNG and just grab randomness from the host?

> Standard watchdog device (isn't it time you'll try qemu?)  isn't about performance and if that's all the functionality you need it should work fine.

Don't understand me wrong, I'm not saying that there's something with the watchdog driver in qemu. All I want is to write a watchdog driver for lkvm which can take advantage of the fact it runs within a guest.

> btw: check the virtio-trace series that was just send in a parallel thread.

Will do!

> Cheers,
> Dor
> 
> 
> 

  reply	other threads:[~2012-07-24 13:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-23 20:32 [RFC 0/2] virtio: provide a way for host to monitor critical events in the device Sasha Levin
2012-07-23 20:32 ` [RFC 1/2] virtio: Introduce virtio-notifier Sasha Levin
2012-07-23 20:32 ` [RFC 2/2] kvm tools: support virtio-notifier Sasha Levin
2012-07-24  4:55 ` [RFC 0/2] virtio: provide a way for host to monitor critical events in the device Rusty Russell
2012-07-24  8:26   ` Dor Laor
2012-07-24 12:30     ` Sasha Levin
2012-07-24 12:46       ` Dor Laor
2012-07-24 13:01         ` Sasha Levin [this message]
2012-07-25  0:36           ` Rusty Russell
2012-07-25  8:46             ` Amit Shah
2012-07-24 12:23   ` Sasha Levin
2012-07-24  7:44 ` Gleb Natapov
2012-07-24 12:26   ` Sasha Levin
     [not found]   ` <500E9479.3050405@gmail.com>
2012-07-24 12:28     ` Gleb Natapov
2012-07-24 12:31       ` Sasha Levin
2012-07-24 12:33         ` Gleb Natapov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=500E9CC7.9020201@gmail.com \
    --to=levinsasha928@gmail.com \
    --cc=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=dlaor@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=penberg@kernel.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=wency@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).