|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Deadlock in stdvga_mem_accept() with emulation
>>> On 13.07.15 at 11:05, <Paul.Durrant@xxxxxxxxxx> wrote:
> --- a/xen/arch/x86/hvm/stdvga.c
> +++ b/xen/arch/x86/hvm/stdvga.c
> @@ -490,11 +490,18 @@ static bool_t stdvga_mem_accept(const struct
> hvm_io_handle
> {
> struct hvm_hw_stdvga *s = ¤t->domain->arch.hvm_domain.stdvga;
>
> + /*
> + * The range check must be done without taking any locks, to avoid
> + * deadlock when hvm_mmio_internal() is called from
> + * hvm_copy_to/from_guest_phys() in hvm_process_io_intercept().
> + */
> + if ( (hvm_mmio_first_byte(p) < VGA_MEM_BASE) ||
> + (hvm_mmio_last_byte(p) >= (VGA_MEM_BASE + VGA_MEM_SIZE)) )
> + return 0;
> +
> spin_lock(&s->lock);
>
> - if ( !s->stdvga ||
> - (hvm_mmio_first_byte(p) < VGA_MEM_BASE) ||
> - (hvm_mmio_last_byte(p) >= (VGA_MEM_BASE + VGA_MEM_SIZE)) )
> + if ( !s->stdvga )
> goto reject;
>
> if ( p->dir == IOREQ_WRITE && p->count > 1 )
But won't the problem continue to exist if the address falls within the
VGA range? I.e. isn't the problem that the two uses of
hvm_mmio_internal() are quite different - while
hvm_hap_nested_page_fault() immediately afterwards calls a
handle_mmio() variant (which would even seem to call for the lock not
getting dropped between them), __hvm_copy() uses it as just a check.
I.e. perhaps better to convert the lock to a recursive one?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |