From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46901) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDA04-0006mo-OV for qemu-devel@nongnu.org; Wed, 06 Mar 2013 03:47:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UDA02-0006UI-L0 for qemu-devel@nongnu.org; Wed, 06 Mar 2013 03:47:00 -0500 Received: from [222.73.24.84] (port=15832 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDA02-0006Ss-Aw for qemu-devel@nongnu.org; Wed, 06 Mar 2013 03:46:58 -0500 Date: Wed, 6 Mar 2013 16:46:58 +0800 From: Hu Tao Message-ID: <20130306084658.GA4719@localhost.localdomain> References: <20130303091738.GB23616@redhat.com> MIME-Version: 1.0 In-Reply-To: <20130303091738.GB23616@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Subject: Re: [Qemu-devel] [PATCH v13 0/8] pv event interface between host and guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Peter Maydell , kvm list , "Michael S. Tsirkin" , Jan Kiszka , qemu-devel , Markus Armbruster , Blue Swirl , Orit Wasserman , Juan Quintela , Alexander Graf , Andrew Jones , Alex Williamson , Sasha Levin , Stefan Hajnoczi , Luiz Capitulino , KAMEZAWA Hiroyuki , Kevin Wolf , Anthony Liguori , Marcelo Tosatti , "linux-kernel@vger.kernel.org" , Paolo Bonzini On Sun, Mar 03, 2013 at 11:17:38AM +0200, Gleb Natapov wrote: > On Thu, Feb 28, 2013 at 08:13:10PM +0800, Hu Tao wrote: > > This series implements a new interface, kvm pv event, to notify host when > > some events happen in guest. Right now there is one supported event: guest > > panic. > > > What other event do you have in mind? Is interface generic enough to > accommodate future, yet unknown, events. It allows to pass only one > integer specifying even type, what if additional info is needed? My be guest crash, lockup, or warning.[1] But the first purpose is to do panic notification(panic event). Since at the point the guest is panicked, I think it's better to keep the interface as simple as possible. [1] http://wiki.qemu.org/Features/PVCrashDetection > stop pretending that device is generic and make it do once thing but do you mean make the interface just do panic notification? > it well? For generic even passing interface (whatever it may be needed > for) much more powerful virtio should be used. > > On implementation itself I do not understand why is this kvm specific. > The only thing that makes it so is that you hook device initialization > into guest kvm initialization code, but this is obviously incorrect. > What stops QEMU tcg or Xen from reusing the same device for the same > purpose except the artificial limitation in a guest. > > Reading data from a random ioports is not how you discover platform > devices in 21 century (and the data you read from unassigned port is not > guarantied to be zero, it may depend on QEMU version), you use ACPI for > that and Marcelo already pointed that to you. Having little knowledge of > ACPI (we all do) is not a good reason to not doing it. We probably need > to reserve QEMU specific ACPI Plug and Play hardware ID to define our own Do we have to request the ID from some orgnazation? > devices. After that you will be able to create device with _HID(QEMU0001) QMU0001, I think. EISA ID requires it to have only 3 letters for PNP ID. > in DSDT that supplies address information (ioport to use) and capability > supported. Guest uses acpi_get_devices() to discover a platform device by > its name (QEMU0001). Then you put the driver for the platform device > into drivers/platform/x86/ and QEMU/kvm/Xen all will be able to use it. Thanks for the information! > > On QEMU side of things I cannot comment much on how QOMified the device > is (it should be), I hope other reviews will verify it, but I noticed > that device is only initialized for PIIX, what about Q35? > > -- > Gleb.