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

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

Hello,

Thanks, this is very interesting.

On Sat, Dec 01, 2018 at 09:21:00AM -0700, Rian Quinn wrote:
> We finally have a Linux PVH guest up and running (using an initramfs right
> now). I have posted a quick status update video on YouTube that shows our
> progress of getting a Windows Dom0 working (which is one of the many goals
> of our research).
> https://www.youtube.com/watch?v=xzTKBek-g0k
> 
> As promised in the x86 Community Call, here is the list of things that a
> PVH Linux guest requires. You can see the code for this here:
> https://github.com/rianquinn/hyperkernel/blob/hyperkernel_1/bfvmm/src/hve/arch/intel_x64/xen/xen_op.cpp
> and here:
> https://github.com/rianquinn/hyperkernel/blob/hyperkernel_1/bfexec/src/main.c
> 
> I would love to put this information somewhere in Xen's project (i.e. wiki
> or source), but I am not sure what you would prefer. Any ideas?
> 
> Finally, keep in mind that we will likely keep adding to this list as we
> add more features (like front/back support, xenstore, etc...)
> 
> Thanks,
> - Rian
> 
> CPUID:
> - XEN_CPUID_LEAF(0)
> - XEN_CPUID_LEAF(1)
> - XEN_CPUID_LEAF(2)
> - XEN_CPUID_LEAF(4)
> - 0x0, 0x1, 0x2, 0x4, 0x6, 0x7, 0xA, 0xB, 0xD, 0xF, 0x10, 0x15, 0x16
> - 0x80000000, 0x80000001, 0x80000002, 0x80000003, 0x80000004
> - 0x80000007, 0x80000008
> 
> MSRs:
> - Hypercall page (dynamic)
> - ia32_star
> - ia32_lstar
> - ia32_cstar
> - ia32_fmask
> - ia32_kernel_gs_base
> - ia32_pat
> - ia32_efer
> - ia32_fs_base
> - ia32_gs_base
> - ia32_sysenter_cs
> - ia32_sysenter_eip
> - ia32_sysenter_esp
> - ia32_apic_base
> - platform_info
> - 0x34, 0x64E, 0x140, 0x1A0, 0x6e0
> 
> 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
> - 0x70
> - 0x71
> - 0x3FE (any ideas)?

Serial port poking?

Again would be interesting to know the Linux code that's poking
this.

> - 0x42, 0x43, 0x61
> - XEN_IOPORT_BASE (since QEMU is not used, why is this needed?)

IIRC the PVH code path in Linux is almost the same as the HVM one,
that's why this port is poked in order to see whether there are
emulated devices to disable. I think this is expected and perfectly
fine.

> 
> Hypercalls:
> - XENMEM_decrease_reservation
> - XENMEM_add_to_physmap_handler
> - XENMEM_memory_map_handler
> - XENVER_get_features_handler
> - GNTTABOP_query_size_handler
> - GNTTABOP_set_version_handler
> - EVTCHNOP_init_control_handler
> - EVTCHNOP_expand_array_handler
> - EVTCHNOP_alloc_unbound_handler
> - EVTCHNOP_bind_ipi_handler
> - EVTCHNOP_bind_virq_handler
> - EVTCHNOP_bind_vcpu_handler
> - EVTCHNOP_send_handler
> - HVMOP_set_param_handler
> - HVMOP_get_param_handler
> - HVMOP_pagetable_dying_handler
> 
> Memory:
> - Shared info page
> - Start info struct (PVH)
> - Initial GDT, IDT, TSS
> - Command line page
> - ACPI (FSDT, DSDT, MADT)
> - xAPIC page
> - Real-mode trampoline (this was weird)

APs for PVH can be started using the native way, which means they are
started in real mode, that's why Linux uses the real mode trampoline.

> - DMI, Video Bios, MP Table, and some legacy ROMs

Legacy ROMs from which device?

Also there's no MP tables or video BIOS at all, so I guess this is
Linux trying to find the BDA and friends in the low 1MB?

Thanks, Roger.

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