Re: [Xen-devel] [PATCH RFC v3 0/6] HVM x86 deprivileged mode summary

[Ben Catterall <Ben.Catterall@xxxxxxxxxx>]

Hi all,

Here are two Python scripts which I have used to collect performance 
benchmarks for this series. I am putting them here in case they are useful.
Ben

On 11/09/15 17:08, Ben Catterall wrote:
> Hi all,
>
> I have now finished my internship at Citrix and am posting this final version of
> my RFC series. I would like to express my thanks to all of those who have taken
> the time to review, comment and discuss this series, as well as to my colleagues
> who have provided excellent guidance and help. I have learned a great deal and
> have greatly enjoyed working with all of you. Thank you.
>
> Hopefully the series will be beneficial. I believe that it has shown that a
> deprivileged mode in Xen is a possible and viable option, as long as performance
> impact vs security is carefully considered on a case-by-case basis. The end of
> this series contains an example of moving some of the vpic into deprivileged
> mode which has allowed me to test and verify that the feature works. There are
> enhancements and some clean up which is needed but, after that, the feature
> could be deployed to HVM devices currently found in Xen such as the VPIC.
>
> Patches one to four are (hopefully) now fairly stable. Patch 5 is the new
> system call and deprivileged dispatch mode which is new to this series. Patch 6
> is also new and is a demonstration of using this for the vpic and hass mainly
> been used to test and exercise this feature.
>
> As this patch series is in RFC, there are some debug printks which should be
> removed when/if it leaves RFC but, they are useful in fixing the known issue so
> I have left them in until that can be resolved.
>
> There are some efficiency savings that can be made and an instance of a general
> issue (detailed later) which will need to be addressed.
>
> Many thanks once again,
> Ben
>
> TODOs
> -----
> There is a set of TODOs in this patch series, some issues in the later patches
> which need addressing and some other considerations which I've summarised here.
>
> Patch 1:
>   - Consider hvm_deprivileged_map_* and an efficiency saving by mapping in 
> larger
>     pages. See the TODO at the top of the L4 version of this method.
>
> Patch 2:
>   - We have a much more heavyweight version of the deprivileged mode context
>     switch after testing for AMD SVM found that this was necessary. However,
>     the FPU is currently also saved and this may not be necessary. Consideration
>     is needed to work out if we can cut this down even more.
>
> Patch 4:
>   - The watchdog timer is hooked currently to kill deprivileged mode operations
>     that run for too long and is hardcoded to be at least one watchdog tick and
>     at most two. This may want to be refined.
>
> Patch 5:
>   - Alias data for deprivileged mode. There is a large comment at the top of
>     deprivileged_syscall.c which outlines considerations.
>   - Check if we need to map_domain_page the pages when we do the copy in
>     hvm_deprivileged_copy_data{to/from}
>   - Check for unsigned integer wrapping on addition in
>     hvm_deprivileged_copy_data_{to/from}
>   - Move hvm_deprivileged_syscall into the syscall macro. It's a stub and
>     unless extra code is needed there it can be folded into the macro.
>   - Check maintainers' thoughts on the deprivileged mode function checks in
>     hvm_deprivileged_user_mode. See the TODO comment.
>
> Patches 5 & 6:
>   - Fix/work around the GCC switch statement issue.
>
>
> KNOWN ISSUES
> ------------
>   - Page fault for vpic_ioport_write due to GCC switch statements placing the
>     jump table in .rodata which is in the privileged mode area.
>
>     This has been traced to the first of the switch statements in the function.
>     Though other switches in that function may also be affected.
>     Compiled using GCC 4.9.2-10.
>
>     You can get the offset into this function by doing:
>     (RIP - (depriv_vpic_ioport_write - __hvm_deprivileged_text_start))
>
>     It appears to be a built-in default of GCC to put switch jump tables in
>     .rodata or .text and there does not appear to be a way to change this
>     (except to patch the compiler, though hopefully there _is_ another
>     option I just haven't been able to find...). Note that GCC will not
>     necessarily allocate jump tables for each switch statment, it appears to
>     depends on a number of factors such as the optimiser, the number of cases,
>     the type of the case, compiler version etc.
>
>     Thus, when we relocate a deprivileged method containing code using a switch
>     statement which GCC has created a jump table for, this leads to a page
>     fault. This is because we have not mapped in the rodata section
>     as we should not (depriv should not have access to it).
>
>     A workaround would be to patch the generated assembly so that this table is
>     moved into hvm_deprivileged.rodata. This can be done by adding,
>     .section .hvm_deprivileged.rodata, around the generated table. We can then
>     relocate this.
>
>     Note that GCC is using RIP-relative addressing for this, so the offset
>     of depriv .rodata to the depriv .text segment will need to be the same
>     when it is mapped in.
>
>
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

Attachment: generator.py
Description: Text Data

Attachment: hvm_test_depriv.py
Description: Text Data

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