Re: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.12.14 at 01:21, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 08/12/2014 20:00, Konrad Rzeszutek Wilk wrote:
>> On Mon, Dec 08, 2014 at 07:03:19PM +0000, Andrew Cooper wrote:
>>> XEN_DOMCTL_memory_mapping hypercall fails with EPERM where it didn't in
>>> xen-4.4, given identical parameters.  The hypercall gained an extra
>>> permission check as part of 0561e1f01e.  Our usecase here is a daemon in
>>> dom0 mapping guest RAM to emulate a graphics card, but I currently don't
>>> see how that is incompatible with the new permissions check.
>> I presume the daemon also does 'XEN_DOMCTL_iomem_permission' to grant
>> the other domain access to its RAM? And before it makes the
>> XEN_DOMCTL_memory_mapping hypercall.
> 
> This is purely an implementer of the ioreq server infrastructure
> providing an emulated set of BARs in the guest as qemu would, but
> without using dom0 map-foreign powers.  The gfn ranges in question are
> regular guest RAM as far as I am aware, and should not require any
> special io permissions.
> 
> Either way, the identified changeset has apparently caused a regression,
> but I am not yet certain whether it is legitimately disabling something
> which should not have worked in the first place, or whether it is a
> change which needs reconsidering.

Actually I think this is still too lax: When we set up Dom0's iomem
permissions, we blindly add all memory, when we should only add
all I/O memory (or better, exclude all RAM). Iiuc such a change
would similarly break your daemon, without need for Arianna's.

Jan


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