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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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.

> The non-string "else" path was enabled
> solely on the basis that it was possible to be made work without
> much extra effort. And while (without pass-through) it shouldn't
> be needed for PVH DomU-s, it also should do no harm.

Ack.


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