[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v1 4/7] x86/vmx: add do_vmtrace_op
----- 18 cze 2020 o 5:20, Tamas K Lengyel tamas.k.lengyel@xxxxxxxxx napisał(a): >> >> + >> >> + a.mfn = v->arch.hvm.vmx.ipt_state->output_base >> PAGE_SHIFT; >> > >> > This will not work for translated domains, ie: a PVH or HVM domain >> > won't be able to use this interface since it has no way to request the >> > mapping of a specific mfn into it's physmap. I think we need to take >> > this into account when deciding how the interface should be, so that >> > we don't corner ourselves with a PV only interface. >> >> Please be aware that this is only going to be used by Dom0. Is is >> well-supported >> case that somebody is using PVH/HVM Dom0? >> >> I think that all Virtual Machine Introspection stuff currently requires to >> have >> Dom0 PV. Our main goal is to have this working well in combo with VMI. > > FYI the VMI interface doesn't require a PV domain. It works fine from > PVH dom0 or even from a secondary privileged HVM DomU as well, > provided you have the right XSM policy to allow that. > > Tamas It was previously stated that: > PVH or HVM domain > won't be able to use this interface since it has no way to request the > mapping of a specific mfn into it's physmap. but however, taking LibVMI as an example: https://github.com/libvmi/libvmi/blob/c461e20ae88bc62c08c27f50fcead23c27a30f9e/libvmi/driver/xen/xen.c#L51 An essential abstraction xen_get_memory() relies on xc_map_foreign_range(). Doesn't this mean that it's not usable from PVH or HVM domains, or did I got it all wrong? Best regards, Michał Leszczyński CERT Polska
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |