pvops upstream status

pvops upstream status

[Juergen Gross]

Hi,

I'd like to update the wiki page

http://wiki.xenproject.org/wiki/XenParavirtOps

regarding the current status of the pvops kernel. I've just started to
collect the missing bits and who is working on them. Up to now I have a
SUSE internal list, some data from Konrad, and, of course, the EFI
patches sent by Daniel last week:

- EFI support (patches posted by Daniel Kiper on 13.06.2014)
- use of PAT (i.e. WC memory type) not possible
- microcode loader (runtime)
- 500Gb+ support
- expected to be dead (under Xen) code cannot be easily verified to
   indeed be dead (e.g. IOMMU, PCI ATS, PRI, and PASID), leaving the
   risk of bad interaction between hypervisor and Dom0 if a new, active
   user of that code appears and goes unnoticed
- user mode pvclock
- possibly not suitable for pre-4.0.1 hypervisor (definitely not as
   Dom0)
- blktap (blktap3 replacement stalled)
- pvSCSI
- pvUSB
- oprofile (perf implementation having got started by Boris)
- some SUSE internal enhancement patches

Done:
- memory hotplug (available 3.9)
- ACPI Sx handling (3.11)
- not using ticket locks (3.12)
- NMI injection/delivery (3.12)
- kexec (implementation not requiring a kernel layer in place)
- MSI-X possibly broken (fixed in 3.14)
- multi-vector MSI (3.15)

I'll add above stuff to the wiki. Any further information is appreciated
especially regarding who is currently working on any of the above or not
mentioned topics. Missing topics not mentioned here with nobody working
on them are welcomed, too.


Juergen

Re: pvops upstream status

[Konrad Rzeszutek Wilk]

On Tue, Jun 17, 2014 at 11:52:37AM +0200, Juergen Gross wrote:
> Hi,
> 
> I'd like to update the wiki page
> 
> http://wiki.xenproject.org/wiki/XenParavirtOps
> 
> regarding the current status of the pvops kernel. I've just started to
> collect the missing bits and who is working on them. Up to now I have a
> SUSE internal list, some data from Konrad, and, of course, the EFI
> patches sent by Daniel last week:
> 
> - EFI support (patches posted by Daniel Kiper on 13.06.2014)
> - use of PAT (i.e. WC memory type) not possible
> - microcode loader (runtime)
> - 500Gb+ support
> - expected to be dead (under Xen) code cannot be easily verified to
>   indeed be dead (e.g. IOMMU, PCI ATS, PRI, and PASID), leaving the
>   risk of bad interaction between hypervisor and Dom0 if a new, active
>   user of that code appears and goes unnoticed
> - user mode pvclock

that would something I had been looking at and hope to have some
patches soon out.

> - possibly not suitable for pre-4.0.1 hypervisor (definitely not as
>   Dom0)
> - blktap (blktap3 replacement stalled)
> - pvSCSI
> - pvUSB
> - oprofile (perf implementation having got started by Boris)
> - some SUSE internal enhancement patches
> 
> Done:
> - memory hotplug (available 3.9)
> - ACPI Sx handling (3.11)
> - not using ticket locks (3.12)
> - NMI injection/delivery (3.12)
> - kexec (implementation not requiring a kernel layer in place)
> - MSI-X possibly broken (fixed in 3.14)
> - multi-vector MSI (3.15)
> 
> I'll add above stuff to the wiki. Any further information is appreciated
> especially regarding who is currently working on any of the above or not
> mentioned topics. Missing topics not mentioned here with nobody working
> on them are welcomed, too.
> 
> 
> Juergen
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: pvops upstream status

[Fabio Fantoni]

[-- Attachment #1: Type: text/plain, Size: 1942 bytes --]

Il 17/06/2014 11:52, Juergen Gross ha scritto:
> Hi,
>
> I'd like to update the wiki page
>
> http://wiki.xenproject.org/wiki/XenParavirtOps
>
> regarding the current status of the pvops kernel. I've just started to
> collect the missing bits and who is working on them. Up to now I have a
> SUSE internal list, some data from Konrad, and, of course, the EFI
> patches sent by Daniel last week:
>
> - EFI support (patches posted by Daniel Kiper on 13.06.2014)
> - use of PAT (i.e. WC memory type) not possible
> - microcode loader (runtime)
> - 500Gb+ support
> - expected to be dead (under Xen) code cannot be easily verified to
>   indeed be dead (e.g. IOMMU, PCI ATS, PRI, and PASID), leaving the
>   risk of bad interaction between hypervisor and Dom0 if a new, active
>   user of that code appears and goes unnoticed
> - user mode pvclock
> - possibly not suitable for pre-4.0.1 hypervisor (definitely not as
>   Dom0)
> - blktap (blktap3 replacement stalled)

I think blktap is no more needed, qdisk of qemu upstream (already used 
by xen) has much superior performance.
One my first benchmark of long time ago in attachment.

> - pvSCSI
> - pvUSB
> - oprofile (perf implementation having got started by Boris)
> - some SUSE internal enhancement patches
>
> Done:
> - memory hotplug (available 3.9)
> - ACPI Sx handling (3.11)
> - not using ticket locks (3.12)
> - NMI injection/delivery (3.12)
> - kexec (implementation not requiring a kernel layer in place)
> - MSI-X possibly broken (fixed in 3.14)
> - multi-vector MSI (3.15)
>
> I'll add above stuff to the wiki. Any further information is appreciated
> especially regarding who is currently working on any of the above or not
> mentioned topics. Missing topics not mentioned here with nobody working
> on them are welcomed, too.
>
>
> Juergen
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


[-- Attachment #2: blktap2_vs_qdisk.JPG --]
[-- Type: image/jpeg, Size: 149719 bytes --]

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: pvops upstream status

[Juergen Gross]

On 06/17/2014 12:55 PM, Fabio Fantoni wrote:
> Il 17/06/2014 11:52, Juergen Gross ha scritto:
>> Hi,
>>
>> I'd like to update the wiki page
>>
>> http://wiki.xenproject.org/wiki/XenParavirtOps
>>
>> regarding the current status of the pvops kernel. I've just started to
>> collect the missing bits and who is working on them. Up to now I have a
>> SUSE internal list, some data from Konrad, and, of course, the EFI
>> patches sent by Daniel last week:
>>
>> - EFI support (patches posted by Daniel Kiper on 13.06.2014)
>> - use of PAT (i.e. WC memory type) not possible
>> - microcode loader (runtime)
>> - 500Gb+ support
>> - expected to be dead (under Xen) code cannot be easily verified to
>>   indeed be dead (e.g. IOMMU, PCI ATS, PRI, and PASID), leaving the
>>   risk of bad interaction between hypervisor and Dom0 if a new, active
>>   user of that code appears and goes unnoticed
>> - user mode pvclock
>> - possibly not suitable for pre-4.0.1 hypervisor (definitely not as
>>   Dom0)
>> - blktap (blktap3 replacement stalled)
>
> I think blktap is no more needed, qdisk of qemu upstream (already used
> by xen) has much superior performance.
> One my first benchmark of long time ago in attachment.

Okay, noted. We'll have to verify that all blktap protocols and
scenarios are handled properly and with good performance by qdisk.

Thanks, Juergen

Re: pvops upstream status

[Sander Eikelenboom]

Tuesday, June 17, 2014, 3:34:17 PM, you wrote:

> On 06/17/2014 12:55 PM, Fabio Fantoni wrote:
>> Il 17/06/2014 11:52, Juergen Gross ha scritto:
>>> Hi,
>>>
>>> I'd like to update the wiki page
>>>
>>> http://wiki.xenproject.org/wiki/XenParavirtOps
>>>
>>> regarding the current status of the pvops kernel. I've just started to
>>> collect the missing bits and who is working on them. Up to now I have a
>>> SUSE internal list, some data from Konrad, and, of course, the EFI
>>> patches sent by Daniel last week:
>>>
>>> - EFI support (patches posted by Daniel Kiper on 13.06.2014)
>>> - use of PAT (i.e. WC memory type) not possible
>>> - microcode loader (runtime)
>>> - 500Gb+ support
>>> - expected to be dead (under Xen) code cannot be easily verified to
>>>   indeed be dead (e.g. IOMMU, PCI ATS, PRI, and PASID), leaving the
>>>   risk of bad interaction between hypervisor and Dom0 if a new, active
>>>   user of that code appears and goes unnoticed
>>> - user mode pvclock
>>> - possibly not suitable for pre-4.0.1 hypervisor (definitely not as
>>>   Dom0)
>>> - blktap (blktap3 replacement stalled)
>>
>> I think blktap is no more needed, qdisk of qemu upstream (already used
>> by xen) has much superior performance.
>> One my first benchmark of long time ago in attachment.

> Okay, noted. We'll have to verify that all blktap protocols and
> scenarios are handled properly and with good performance by qdisk.

> Thanks, Juergen

Another benchmark:
https://events.linuxfoundation.org/sites/events/files/slides/20131025%20-%20Storage%20Performance%20PDF.pdf

seems to show not that much difference between tapdisk and qdisk (both 
relatively slow compared to blkback)

 --
Sander

Re: pvops upstream status

[Fabio Fantoni]

Il 17/06/2014 15:34, Juergen Gross ha scritto:
> On 06/17/2014 12:55 PM, Fabio Fantoni wrote:
>> Il 17/06/2014 11:52, Juergen Gross ha scritto:
>>> Hi,
>>>
>>> I'd like to update the wiki page
>>>
>>> http://wiki.xenproject.org/wiki/XenParavirtOps
>>>
>>> regarding the current status of the pvops kernel. I've just started to
>>> collect the missing bits and who is working on them. Up to now I have a
>>> SUSE internal list, some data from Konrad, and, of course, the EFI
>>> patches sent by Daniel last week:
>>>
>>> - EFI support (patches posted by Daniel Kiper on 13.06.2014)
>>> - use of PAT (i.e. WC memory type) not possible
>>> - microcode loader (runtime)
>>> - 500Gb+ support
>>> - expected to be dead (under Xen) code cannot be easily verified to
>>>   indeed be dead (e.g. IOMMU, PCI ATS, PRI, and PASID), leaving the
>>>   risk of bad interaction between hypervisor and Dom0 if a new, active
>>>   user of that code appears and goes unnoticed
>>> - user mode pvclock
>>> - possibly not suitable for pre-4.0.1 hypervisor (definitely not as
>>>   Dom0)
>>> - blktap (blktap3 replacement stalled)
>>
>> I think blktap is no more needed, qdisk of qemu upstream (already used
>> by xen) has much superior performance.
>> One my first benchmark of long time ago in attachment.
>
> Okay, noted. We'll have to verify that all blktap protocols and
> scenarios are handled properly and with good performance by qdisk.
>
> Thanks, Juergen
My test was only with raw image, for what I read time ago probably the 
only problem should be with vhd format they said needed improvements on 
qemu but they might have done in the meantime (if I remember good I read 
it 2 year ago).

Re: pvops upstream status

[Daniel Kiper]

On Tue, Jun 17, 2014 at 11:52:37AM +0200, Juergen Gross wrote:
> Hi,
>
> I'd like to update the wiki page
>
> http://wiki.xenproject.org/wiki/XenParavirtOps
>
> regarding the current status of the pvops kernel. I've just started to
> collect the missing bits and who is working on them. Up to now I have a
> SUSE internal list, some data from Konrad, and, of course, the EFI
> patches sent by Daniel last week:
>
> - EFI support (patches posted by Daniel Kiper on 13.06.2014)
> - use of PAT (i.e. WC memory type) not possible
> - microcode loader (runtime)
> - 500Gb+ support
> - expected to be dead (under Xen) code cannot be easily verified to
>   indeed be dead (e.g. IOMMU, PCI ATS, PRI, and PASID), leaving the
>   risk of bad interaction between hypervisor and Dom0 if a new, active
>   user of that code appears and goes unnoticed
> - user mode pvclock
> - possibly not suitable for pre-4.0.1 hypervisor (definitely not as
>   Dom0)
> - blktap (blktap3 replacement stalled)
> - pvSCSI
> - pvUSB
> - oprofile (perf implementation having got started by Boris)
> - some SUSE internal enhancement patches
>
> Done:
> - memory hotplug (available 3.9)
> - ACPI Sx handling (3.11)
> - not using ticket locks (3.12)
> - NMI injection/delivery (3.12)
> - kexec (implementation not requiring a kernel layer in place)

Please remove kexec/kdump stuff from "Work in progress for 3.10" paragraph
or even completely delete it because it is a bit outdated.

Daniel

Re: pvops upstream status

[Stefano Stabellini]

On Tue, 17 Jun 2014, Sander Eikelenboom wrote:
> Tuesday, June 17, 2014, 3:34:17 PM, you wrote:
> 
> > On 06/17/2014 12:55 PM, Fabio Fantoni wrote:
> >> Il 17/06/2014 11:52, Juergen Gross ha scritto:
> >>> Hi,
> >>>
> >>> I'd like to update the wiki page
> >>>
> >>> http://wiki.xenproject.org/wiki/XenParavirtOps
> >>>
> >>> regarding the current status of the pvops kernel. I've just started to
> >>> collect the missing bits and who is working on them. Up to now I have a
> >>> SUSE internal list, some data from Konrad, and, of course, the EFI
> >>> patches sent by Daniel last week:
> >>>
> >>> - EFI support (patches posted by Daniel Kiper on 13.06.2014)
> >>> - use of PAT (i.e. WC memory type) not possible
> >>> - microcode loader (runtime)
> >>> - 500Gb+ support
> >>> - expected to be dead (under Xen) code cannot be easily verified to
> >>>   indeed be dead (e.g. IOMMU, PCI ATS, PRI, and PASID), leaving the
> >>>   risk of bad interaction between hypervisor and Dom0 if a new, active
> >>>   user of that code appears and goes unnoticed
> >>> - user mode pvclock
> >>> - possibly not suitable for pre-4.0.1 hypervisor (definitely not as
> >>>   Dom0)
> >>> - blktap (blktap3 replacement stalled)
> >>
> >> I think blktap is no more needed, qdisk of qemu upstream (already used
> >> by xen) has much superior performance.
> >> One my first benchmark of long time ago in attachment.
> 
> > Okay, noted. We'll have to verify that all blktap protocols and
> > scenarios are handled properly and with good performance by qdisk.
> 
> > Thanks, Juergen
> 
> Another benchmark:
> https://events.linuxfoundation.org/sites/events/files/slides/20131025%20-%20Storage%20Performance%20PDF.pdf
> 
> seems to show not that much difference between tapdisk and qdisk (both 
> relatively slow compared to blkback)

qdisk should be a very good replacement, even better than blktap unless
the guest image format is vhd, in that case blktap has better support
for the format.
Of course guest images can be converted to raw or qcow2 using
qemu-img.

Re: pvops upstream status - VHD

[Philipp Hahn]

Hello,

On 17.06.2014 16:28, Fabio Fantoni wrote:
> My test was only with raw image, for what I read time ago probably the
> only problem should be with vhd format they said needed improvements on
> qemu but they might have done in the meantime (if I remember good I read
> it 2 year ago).

VHD in QEMU had very little changes, differencing images are still not
supported (I have a WIP patch which supports reading, but write seems to
be broken). What's also missing it support for the journaling extension,
which vhd-utils supports.
VHDX support seems to be a lot better in QEMU (and non-existent in
chd-utils), which AFAIK has removed some limitations of VHD (image size,
journaling support), so my personal opinion would classify VHD as
legacy, for which read support is good to have, but write support is
less important.

Philipp