[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> 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(). 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.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.