Namhyung Kim
2016-Nov-15 14:36 UTC
[PATCH 1/3] virtio: Basic implementation of virtio pstore driver
Hi, On Tue, Nov 15, 2016 at 10:57:29AM +0100, Paolo Bonzini wrote:> > > On 15/11/2016 06:06, Michael S. Tsirkin wrote: > > On Tue, Nov 15, 2016 at 01:50:21PM +0900, Namhyung Kim wrote: > >> Hi Michael, > >> > >> On Thu, Nov 10, 2016 at 06:39:55PM +0200, Michael S. Tsirkin wrote: > >>> On Sat, Aug 20, 2016 at 05:07:42PM +0900, Namhyung Kim wrote: > >>>> The virtio pstore driver provides interface to the pstore subsystem so > >>>> that the guest kernel's log/dump message can be saved on the host > >>>> machine. Users can access the log file directly on the host, or on the > >>>> guest at the next boot using pstore filesystem. It currently deals with > >>>> kernel log (printk) buffer only, but we can extend it to have other > >>>> information (like ftrace dump) later. > >>>> > >>>> It supports legacy PCI device using single order-2 page buffer. > >>> > >>> Do you mean a legacy virtio device? I don't see why > >>> you would want to support pre-1.0 mode. > >>> If you drop that, you can drop all cpu_to_virtio things > >>> and just use __le accessors. > >> > >> I was thinking about the kvmtools which lacks 1.0 support AFAIK. > > > > Unless kvmtools wants to be left behind it has to go 1.0. > > And it also has to go ACPI. Is there any reason, apart from kvmtool, to > make a completely new virtio device, with no support in existing guests, > rather than implement ACPI ERST?Well, I know nothing about ACPI. It looks like a huge spec and I don't want to dig into it just for this. What I want is to speed up dumping guest kernel message (especially for ftrace dump). Thanks, Namhyung
Paolo Bonzini
2016-Nov-15 14:38 UTC
[PATCH 1/3] virtio: Basic implementation of virtio pstore driver
On 15/11/2016 15:36, Namhyung Kim wrote:> Hi, > > On Tue, Nov 15, 2016 at 10:57:29AM +0100, Paolo Bonzini wrote: >> >> >> On 15/11/2016 06:06, Michael S. Tsirkin wrote: >>> On Tue, Nov 15, 2016 at 01:50:21PM +0900, Namhyung Kim wrote: >>>> Hi Michael, >>>> >>>> On Thu, Nov 10, 2016 at 06:39:55PM +0200, Michael S. Tsirkin wrote: >>>>> On Sat, Aug 20, 2016 at 05:07:42PM +0900, Namhyung Kim wrote: >>>>>> The virtio pstore driver provides interface to the pstore subsystem so >>>>>> that the guest kernel's log/dump message can be saved on the host >>>>>> machine. Users can access the log file directly on the host, or on the >>>>>> guest at the next boot using pstore filesystem. It currently deals with >>>>>> kernel log (printk) buffer only, but we can extend it to have other >>>>>> information (like ftrace dump) later. >>>>>> >>>>>> It supports legacy PCI device using single order-2 page buffer. >>>>> >>>>> Do you mean a legacy virtio device? I don't see why >>>>> you would want to support pre-1.0 mode. >>>>> If you drop that, you can drop all cpu_to_virtio things >>>>> and just use __le accessors. >>>> >>>> I was thinking about the kvmtools which lacks 1.0 support AFAIK. >>> >>> Unless kvmtools wants to be left behind it has to go 1.0. >> >> And it also has to go ACPI. Is there any reason, apart from kvmtool, to >> make a completely new virtio device, with no support in existing guests, >> rather than implement ACPI ERST? > > Well, I know nothing about ACPI. It looks like a huge spec and I > don't want to dig into it just for this.ERST (error record serialization table) is a small subset of the ACPI spec. Paolo
Namhyung Kim
2016-Nov-16 07:04 UTC
[PATCH 1/3] virtio: Basic implementation of virtio pstore driver
Hi, On Tue, Nov 15, 2016 at 11:38 PM, Paolo Bonzini <pbonzini at redhat.com> wrote:> > > On 15/11/2016 15:36, Namhyung Kim wrote: >> Hi, >> >> On Tue, Nov 15, 2016 at 10:57:29AM +0100, Paolo Bonzini wrote: >>> >>> >>> On 15/11/2016 06:06, Michael S. Tsirkin wrote: >>>> On Tue, Nov 15, 2016 at 01:50:21PM +0900, Namhyung Kim wrote: >>>>> Hi Michael, >>>>> >>>>> On Thu, Nov 10, 2016 at 06:39:55PM +0200, Michael S. Tsirkin wrote: >>>>>> On Sat, Aug 20, 2016 at 05:07:42PM +0900, Namhyung Kim wrote: >>>>>>> The virtio pstore driver provides interface to the pstore subsystem so >>>>>>> that the guest kernel's log/dump message can be saved on the host >>>>>>> machine. Users can access the log file directly on the host, or on the >>>>>>> guest at the next boot using pstore filesystem. It currently deals with >>>>>>> kernel log (printk) buffer only, but we can extend it to have other >>>>>>> information (like ftrace dump) later. >>>>>>> >>>>>>> It supports legacy PCI device using single order-2 page buffer. >>>>>> >>>>>> Do you mean a legacy virtio device? I don't see why >>>>>> you would want to support pre-1.0 mode. >>>>>> If you drop that, you can drop all cpu_to_virtio things >>>>>> and just use __le accessors. >>>>> >>>>> I was thinking about the kvmtools which lacks 1.0 support AFAIK. >>>> >>>> Unless kvmtools wants to be left behind it has to go 1.0. >>> >>> And it also has to go ACPI. Is there any reason, apart from kvmtool, to >>> make a completely new virtio device, with no support in existing guests, >>> rather than implement ACPI ERST? >> >> Well, I know nothing about ACPI. It looks like a huge spec and I >> don't want to dig into it just for this. > > ERST (error record serialization table) is a small subset of the ACPI spec.Not sure how independent ERST is from ACPI and other specs. It looks like referencing UEFI spec at least. Btw, is the ERST used for pstore only (in Linux)? Also I need to control pstore driver like using bigger buffer, enabling specific message types and so on if ERST supports. Is it possible for ERST to provide such information? Thanks, Namhyung
Apparently Analagous Threads
- [PATCH 1/3] virtio: Basic implementation of virtio pstore driver
- [PATCH 1/3] virtio: Basic implementation of virtio pstore driver
- [PATCH 1/3] virtio: Basic implementation of virtio pstore driver
- [PATCH 1/3] virtio: Basic implementation of virtio pstore driver
- [PATCH 1/3] virtio: Basic implementation of virtio pstore driver