Xen summit: x86 emulator design session

Xen summit: x86 emulator design session

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 3265 bytes --]

Design: one large switch statement, maintainable by Andrew and Jan, but probably 
not for someone else. Even hard for Jan as working only sometimes on it.
Additional problem is the need for reviews, as the barrier for doing reviews is 
quite high (even for Andrew).

This is problematic regarding to rework the emulator as nobody is really looking 
at the patches (pending since more than 1 year). Who will take over from Jan 
after his retirement (in 11 years).

What needs to be done to unblock Jan's rework and further improvements?

George: sometimes reviewing Jan's patches. Emulation is done not by simulating 
the instructions, but to setup the input data and to then execute the single 
instructions, emulating only the memory accesses.

Marek: how does testing look like?

Jan/George: emulator can be compiled into the hypervisor or into the test code 
and then the tests are run, e.g. AFL (detecting basically wrong assertions). 
Tests will find regressions when adding new instructions.
What is missing is some automatic verification between native and emulated 
instructions are having the same results.

Jan: refactoring is really needed, but stuck due to above reasons.

Juergen: no indirect calls wanted, what about generating the code from an 
initial table.

Jan: structure is complicated, e.g. using quite some gotos to common code

George: would not be certifyable

Juergen: just a way to avoid indirect calls

Jan: gotos could be replaced by calls given that all state would be passed via 
params or a common struct.

Juergen: I could probably review some patches, but I'm retiring probably ahead 
of Jan.

Marek: knowing to not use some features, can we disable the emulator?

Jan: if you are not using shadow page tables, emulated graphics, emulated MMIO, 
introspection, ...

George: what about trying to write the new emulator from scratch in a clean way 
while documenting/understanding it by the new maintainer?

Jan: problem is mainly the special case handled basically via the gotos today 
(exceptions, ...)

George: proper test cases would help to do that for verification of a new structure

Jan. e.g. AVX512 instructions are covered only for memory accesses

George: another problem area is interruptability testing

George: maybe we need to find someone doing the work (hiring) for auditing the 
emulator code

Juergen: what about asking e.g. AMD?

Jan/George: maybe people at AMD capable to do that are not interested in Xen

Marek: KVM uses qemu to emulated e.g. emulated VGA memory. What about doing the 
same in Xen?

Jan: not easy, but maybe possible, removing the need to emulate all the SIMD 
stuff etc.

George: what to do with Jan's current pending patches?

Jan: just take missing NAK as silent agreement, given that testing has been 
quite good

George: quite dangerous

Jan: for rework we'd need some more tests for being sure not having broken something

George: add additional AFL tests testing stuff which can then be tested on bare 
metal and compare the results to be the same.

Juergen: what about using some existing selftests (AMD, qemu, ...)? Looking 
especially at qemu TCG tests could be a good way to handle it.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]