Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend

[Austin S Hemmelgarn]

On 2015-03-04 09:09, Juergen Gross wrote:

The main question whether it is worth to consider this alternative is
the performance aspect. Does anyone have an idea which USB devices would
typically be used via pvusb? I'd suspect memory sticks and USB disks
and perhaps webcams being the most performance relevant ones. Is an
additional copy operation of user data acceptable here?

Biggest use-cases I can think of for USB pass-through would be hardware 
'security' devices (fingerprint readers, Yubikeys, SafeNet dongles), 
webcams, and some of the more exotic input devices.  Webcams and input 
devices are probably the most significant performance-wise.


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

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

[Austin S. Hemmelgarn]

On 2017-05-13 19:17, PGNet Dev wrote:

On 5/13/17 3:15 PM, Valentin Vidic wrote:

Try booting without 'hpet=force,verbose clocksource=hpet' and it should
select xen by default:


Nope. Well, not quite ...

With both

'hpet=force,verbose clocksource=hpet'

removed, I end up with

cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc xen
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

But with

clocksource=xen

*explicitly* added

cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc xen
cat /sys/devices/system/clocksource/clocksource0/current_clocksourcexen
xen

and in *console*, NOT dmesg, output,

grep -i hpet tmp.txt
(XEN) ACPI: HPET 9E8298F8, 0038 (r1 SUPERM SMCI--MB  1072009 
AMI.5)
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed0
(XEN) [VT-D] MSI HPET: :f0:0f.0
(XEN) Platform timer is 14.318MHz HPET
[0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM 
SMCI--MB 01072009 AMI. 00
[0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0
[0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM 
SMCI--MB 01072009 AMI. 00
[0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0
[8.515245] hpet_acpi_add: no address or irqs in _CRS
[8.515245] hpet_acpi_add: no address or irqs in _CRS
(XEN) [2017-05-13 23:04:27] HVM1 save: HPET



and

dmesg | grep -i clocksource | grep -v line:
[0.00] clocksource: refined-jiffies: mask: 0x 
max_cycles: 0x, max_idle_ns: 7645519600211568 ns
[0.004000] clocksource: xen: mask: 0x 
max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[0.375709] clocksource: jiffies: mask: 0x 
max_cycles: 0x, max_idle_ns: 764504178510 ns
[4.656634] clocksource: Switched to clocksource xen
[8.912897] clocksource: tsc: mask: 0x 
max_cycles: 0x2c94dffea94, max_idle_ns: 440795361700 ns

jiffies, now? hm. no idea where that came from. and why the 'tsc' ?

So I'm still unclear -- is this^ now, correctly "all" using MSI/HPET?
That depends on what you mean by everything correctly using the HPET. 
Using clocksource=xen (or autoselecting it) will cause the kernel to get 
timing info from Xen.  If you're running as a guest, this is absolutely 
what you want (unless you're using HVM), and with possible limited and 
extremely specific exceptions, this is almost certainly what you want in 
Domain-0 as well.  Given that Xen is using the HPEt for timing itself, 
using clocksource=xen will result in Linux _indirectly_ using the HPET 
through Xen without involving the HPET driver (in essence, Xen is your 
HPET driver in this situation), which will get you essentially the same 
precision that you would get by using the HPET directly.


So, if you just want the precision offered by the HPET, then yes, you 
are getting the same thing through the Xen clocksource.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel