Re: [Xen-devel] PVH Whitelist Results / Windows Dom0

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Dec 04, 2018 at 05:46:38AM +0000, Connor Davis wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, December 3, 2018 1:07 PM, Rian Quinn <rianquinn@xxxxxxxxx> wrote:
> >>> > > IO Ports (some of these are odd):
> >>> > > - 0xCF8 - 0xCFF
> >>> > > - 0x4D0 (odd since PIT and ACPI is disable for everything that might 
> >>> > > need
> >>> > > this)
> >>> >
> >>> > Likely some poking for EISA devices? (same for 0x4D1)
> >>> >
> >>> > Can you trace this to the Linux code that's actually making the call
> >>> > by injecting a trap when this happens?
> >>> >
> >>> > > - 0x4D1
> 
> 0x4D0 and 0x4D1 were touched from apci_early_init -> acpi_pic_sci_set_trigger 
> since
> we don't emulate any IOAPICs yet.

Hm, yes. When I looked into this I couldn't find a way to signal from
ACPI that there's no SCI. The only way seems to be to report
hardware-reduced ACPI, but that has a lot of other implications.

Maybe we could look into adding something to the ACPI spec to signal
there's no SCI even when not using hardware-reduced ACPI?

The FADT IA-PC boot flags field still has plenty of space.

> >>> > > - 0x70
> >>> > > - 0x71
> 
> These are accessed from reassert_nmi. This is only called from default_do_nmi
> in the version the guest is based on (4.20-rc2).
> 
> >>> > > - 0x3FE (any ideas)?
> >>> >
> >>> > Serial port poking?
> >>> >
> >>> > Again would be interesting to know the Linux code that's poking
> >>> > this.
> >>> >
> >>> > > - 0x42, 0x43, 0x61
> 
> These are in pit_calibrate_tsc.

Right, there's no way I'm aware of to signal there's no PIT. Again we
could consider trying to add a field to the IA-PC boot flags field for
this, but I'm not sure how useful it would be since quite a lot of
stuff relies on the existence of a PIT, and by the time FADT gets
checked it might be too late. I've seen the PIT being used very early
during boot due to the fact that it's assumed to be always present on
PC systems.

> The guest was taking this path initially, but
> right now we are abusing cpuid.15h by returning the TSC hz in ecx rather
> than the core crystal. We made a small, temporary hack to the pv 
> interface/linux
> to get this working:
> 
> https://github.com/connojd/linux/commit/6b620ebc4f56129ed068d9995d59e46521abc80b
> 
> In all our attempts to convince linux that TSC is reliable, it inevitably 
> decided that it
> in fact was not. Any thoughts on how to make this not be so dirty?

I'm not that familiar with Linux, do you know why Linux decides the TSC
is not reliable?

Is this based on CPU model, CPUID features, or some kind of test?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel