[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v6 1/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.
On 05/09/16 14:31, Jan Beulich wrote: >>>> On 02.09.16 at 12:47, <yu.c.zhang@xxxxxxxxxxxxxxx> wrote: >> @@ -178,8 +179,27 @@ static int hvmemul_do_io( >> break; >> case X86EMUL_UNHANDLEABLE: >> { >> - struct hvm_ioreq_server *s = >> - hvm_select_ioreq_server(curr->domain, &p); >> + struct hvm_ioreq_server *s = NULL; >> + p2m_type_t p2mt = p2m_invalid; >> + >> + if ( is_mmio ) >> + { >> + unsigned long gmfn = paddr_to_pfn(addr); >> + >> + (void) get_gfn_query_unlocked(currd, gmfn, &p2mt); >> + >> + if ( p2mt == p2m_ioreq_server && dir == IOREQ_WRITE ) >> + { >> + unsigned int flags; >> + >> + s = p2m_get_ioreq_server(currd, &flags); >> + if ( !(flags & XEN_HVMOP_IOREQ_MEM_ACCESS_WRITE) ) >> + s = NULL; >> + } >> + } >> + >> + if ( !s && p2mt != p2m_ioreq_server ) >> + s = hvm_select_ioreq_server(currd, &p); > > What I recall is that we had agreed on p2m_ioreq_server pages > to be treated as ordinary RAM ones as long as no server can be > found. The type check here contradicts that. Is there a reason? I think it must be a confusion as to what "treated like ordinary RAM ones" means. p2m_ram_rw types that gets here will go through hvm_select_ioreq_server(), and (therefore) potentially be treated as MMIO accesses, which is not how "ordinary RAM" would behave. If what you meant was that you want p2m_ioreq_server to behave like p2m_ram_rw (and be treated as MMIO if it matches an iorange) then yes. If what you want is for p2m_ioreq_server to actually act like RAM, then probably something more needs to happen here. -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |