Re: [Xen-devel] [PATCH RFC] ioreq-server: handle the lack of a default emulator properly

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.09.14 at 17:31, <paul.durrant@xxxxxxxxxx> wrote:
> This fix should probably go in 4.5 but this patch is RFC for the moment
> because of uncertainty about what to do for unemulated MMIO accesses.
> Originally I forced a domain crash in this case, but hvmloader actually
> hit the crash because the code that deals with building the ACPI TPM
> info reads from 0xFED40F00 looking for a signature value and there is
> nothing backing this access in my configuration. So, the question is
> whether to whitelist this access in some way or make building that
> table optional in some way so that it is only invoked if an emulated
> TPM is definitely present.

I think in the sense of acting like real hardware, having a definite
point to complete such I/O is quite desirable, as opposed to killing
the guest.

> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2386,8 +2386,7 @@ static struct hvm_ioreq_server 
> *hvm_select_ioreq_server(struct domain *d,
>      if ( list_empty(&d->arch.hvm_domain.ioreq_server.list) )
>          return NULL;
>  
> -    if ( list_is_singular(&d->arch.hvm_domain.ioreq_server.list) ||
> -         (p->type != IOREQ_TYPE_COPY && p->type != IOREQ_TYPE_PIO) )
> +    if ( p->type != IOREQ_TYPE_COPY && p->type != IOREQ_TYPE_PIO )

I'm having some trouble understanding the reason for this change.

Jan


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