Virtualization - Nov 2016 - [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

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

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