Re: [Xen-devel] [PATCH RFC] xen/pvh: use a custom IO bitmap for PVH hardware domains

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.04.15 at 12:45, <roger.pau@xxxxxxxxxx> wrote:
> Hello,
> 
> El 14/04/15 a les 12.31, Jan Beulich ha escrit:
>>>>> On 14.04.15 at 12:01, <roger.pau@xxxxxxxxxx> wrote:
>>> I have one question about the current IO port handling for PVH guests
>>> (DomU and Dom0). There's some code right now in vmx_vmexit_handler
>>> (EXIT_REASON_IO_INSTRUCTION) that's kind PVH specific:
>>>
>>> if ( exit_qualification & 0x10 )
>>> {
>>>     /* INS, OUTS */
>>>     if ( unlikely(is_pvh_vcpu(v)) /* PVH fixme */ ||
>>>          !handle_mmio() )
>>>         hvm_inject_hw_exception(TRAP_gp_fault, 0);
>>> }
>>> else
>>> {
>>>     /* IN, OUT */
>>>     uint16_t port = (exit_qualification >> 16) & 0xFFFF;
>>>     int bytes = (exit_qualification & 0x07) + 1;
>>>     int dir = (exit_qualification & 0x08) ? IOREQ_READ : IOREQ_WRITE;
>>>
>>>     if ( handle_pio(port, bytes, dir) )
>>>         update_guest_eip(); /* Safe: IN, OUT */
>>> }
>>>
>>> Is there any need for DomUs to access the IO ports? I know that FreeBSD
>>> will poke at some of them during boot to scan for devices, but I'm not
>>> sure if we could just make them noops in the PVH case and simply return
>>> garbage.
>> 
>> The PVH special case quoted above is there only to prevent
>> reaching handle_mmio(). 
> 
> Injecting a GP seems like a little bit too much for trapped INS/OUTS, I
> would rather just drop/ignore them if possible.

Dropping them means (silent) data corruption, whereas #GP is a
clear sign that something went wrong. In the end the case will
need to be properly handled anyway, and learning about this
becoming an immediate need will be better through a plainly
crashed domain than through one that (perhaps quite a long
period of time later) died in some obscure way.

Jan


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