[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xen: Filter out MSR write events

On 04/12/2016 12:38 PM, Andrew Cooper wrote:
> On 12/04/16 05:26, Razvan Cojocaru wrote:
>> On 04/11/16 22:18, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Apr 11, 2016 at 07:41:54PM +0300, Razvan Cojocaru wrote:
>>>> This patch only allows introspection-related MSR write events to
>>>> be sent out, improving performance. Should additional events be
>>>> required, they can then simply be added to the list of
>>>> vmx_introspection_force_enabled_msrs[].
>>>> Signed-off-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
>>> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
>>> Thought should there be some .. dynamic mechanism to update
>>> the MSR list? Or remove entries (or temporarily blacklist
>>> the built-one ins), etc?
>> While this should be enough for now (the introspection MSR list is very
>> small, and we're probably the only consumers), that's indeed the way for
>> the future, I think. We should have a set-like container of unique
>> elements that can grow and shrink and can be searched quickly, and add /
>> remove MSRs we're interested in there.
>> The CR write events bitmap approach clearly doesn't work, as there are
>> too many MSRs to be able to select them all with a bitmap in the future.
> The current intercept bitmaps have 4x1K bitmaps, a read and a write bit
> for the low and high MSR indices.
> For introspection purposes, you will also want a bitmap covering the
> hypervisor range.  For now, 3x1K bitmaps should be plenty to cover all
> potentially interesting MSRs.

I see, so for future reference, add a pointer member allocated with
alloc_xenheap_page() and memset() to 0 to struct arch_domain, maybe
named monitor_msrs_bitmap (while removing mov_to_msr_enabled and
mov_to_msr_extended from struct monitor)? This could get allocated on
vm_event_init_domain() and de-allocated on vm_event_cleanup_domain().


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.