On 2019-11-22 11:54, Cornelia Huck wrote:
On Fri, 22 Nov 2019 10:03:21 +0100
Pierre Morel <pmorel@xxxxxxxxxxxxx> wrote:
On 2019-11-21 17:02, Cornelia Huck wrote:
On Thu, 14 Nov 2019 11:11:18 +0100
Pierre Morel <pmorel@xxxxxxxxxxxxx> wrote:
On 2019-11-13 14:05, Cornelia Huck wrote:
On Wed, 13 Nov 2019 13:23:19 +0100
Pierre Morel <pmorel@xxxxxxxxxxxxx> wrote:
- initializing the ORB pointing to a single READ CCW
Out of curiosity: Would using a NOP also be an option?
It will work but will not be handled by this device, css.c intercept it
in sch_handle_start_func_virtual.
AFAIU If we want to have a really good testing environment, for driver
testing for exemple, then it would be interesting to add a new
do_subchannel_work callback like do_subchannel_work_emulation along with
the _virtual and _paththrough variantes.
Having a dedicated callback for emulation, we can answer to any CSS
instructions and SSCH commands, including NOP and TIC.
I guess that depends on what you want to test; if you actually want to
test device emulation as used by virtio etc., you obviously want to go
through the existing _virtual callback :)
The first goal is to test basic I/O from inside the kvm-unit-test,
producing errors and see how the system respond to errors.
In a standard system errors will be generated by QEMU analysing the I/O
instruction after interception.
In a secured guest, we expect the same errors, however we want to check
this.
But we still get the intercepts for all I/O instructions, right? We
just get/inject the parameters in a slightly different way, IIUC.
Not that I disagree with wanting to check this :)
AFAIU the SE firmware, the SIE and KVM first handle the instruction
interception before it comes to the QEMU code.
There are two major changes with secure execution that we want to test,
SE firmware and SIE modifications.
If the instruction is treated by QEMU, then hopefully we get the same
answer as without SE.
This PONG device is intended to be low level, no VIRTIO, and to allow
basic I/O.
Ok, so this is designed to test basic channel I/O handling, not
necessarily if the guest has set up all its control structures
correctly?
More than this it is intended, in the next version, to test answers to
bad configurations and wrong instruction's arguments.
The actual motivation behind my question was:
Is it possible to e.g. throw NOP (or TIC, or something else not
device-specific) at a normal, existing virtio device for test purposes?
You'd end up testing the common emulation code without needing any
extra support in QEMU. No idea how useful that would be.
Writing a VIRTIO driver inside the kvm-unit-test is something we can do
in the future.
As you said, the common code already handle NOP and TIC, the
interpretation of the
CCW chain, once the SSCH has been intercepted is done by QEMU.
I do not think it would be different with SE.
Yes. You don't really need to get the virtio device up on the virtio
side; if recognizing the device correctly via senseID works and you
maybe can do some NOP/TIC commands, you might have a very basic test
without introducing a new device.
Right, but the test is incomplete, as you said before, no write
operation with this procedure.
Testing virtio-ccw via kvm-unit-tests is probably a good idea for the
future.
To sum-up:
in kvm-unit-test: implement all I/O instructions and force instructions
errors, like memory error, operand etc. and expect the right reaction of
the system.
in QEMU, add the necessary infrastructure to test this.
Sounds good to me.
Thanks,
I think the next version will make the purpose of all of it even more
obvious,
and hopefully answers all your questions better.
Best regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
