[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v10 5/6] x86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries.
On 4/3/2017 10:36 PM, Jan Beulich wrote: So this produces the same -EINVAL as the earlier check in context above. I think it would be nice if neither did - -EINUSE for the first (which we don't have, so -EOPNOTSUPP would seem the second bets option there) and -EBUSY for the second would seem more appropriate. If you agree, respective adjustments could be done while committing, if no other reason for a v11 arises. Thanks Jan.But my code shows both will return -EBUSY, instead of -EINVAL for the mapping requirement: /* Unmap ioreq server from p2m type by passing flags with 0. */ if ( flags == 0 ) { /rc = -EINVAL;/ if ( p2m->ioreq.server != s ) goto out; p2m->ioreq.server = NULL; p2m->ioreq.flags = 0; } else { /rc = -EBUSY;/ if ( p2m->ioreq.server != NULL ) goto out; /* * It is possible that an ioreq server has just been unmapped, * released the spin lock, with some p2m_ioreq_server entries * in p2m table remained. We shall refuse another ioreq server * mapping request in such case. */ if ( read_atomic(&p2m->ioreq.entry_count) ) goto out; p2m->ioreq.server = s; p2m->ioreq.flags = flags; }Are you really wanna use -EOPNOTSUPP when p2m->ioreq.server is not NULL for the mapping code? For the unmapping code, -EINVAL is used when the ioreq server to be unmapped is not the designated one. But for this one, I am not sure which one is better: -EINVAL or -EBUSY? Yu _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |