Re: [Xen-devel] [RFC][v2][PATCH 00/14] Fix RMRR

["Chen, Tiejun" <tiejun.chen@xxxxxxxxx>]

On 2015/5/22 17:46, Jan Beulich wrote:
> > > > On 22.05.15 at 11:35, <tiejun.chen@xxxxxxxxx> wrote:
> > As you know all devices are owned by Dom0 firstly before we create any
> > DomU, right? Do we allow Dom0 still own a group device while assign another
> > device in the same group?
> Clearly not, or - just like anything else putting the security of a system
> at risk - only at explicit host admin request.
You're right.

After we discussed internally, we're intending to cover this simply 
since the case of shared RMRR is a rare case according to our previous 
experiences. Furthermore, Xen doesn't have a good existing API to 
directly assign this sort of group devices and even Xen doesn't identify 
these devices,  so currently we always assign devices one by one, right? 
This means we have to put more efforts to concern a good implementation 
to address something like, identification, atomic, hotplug and so on. 
Obviously, this would involve hypervisor and tools at the same time so 
this has a little bit of difficulty to work along with 4.6.
So could we do this separately?

#1. Phase 1 to 4.6

#1.1. Do a simple implementation

We just prevent from that device assignment if we're assigning this sort 
of group devices like this,
@@ -2291,6 +2291,16 @@ static int intel_iommu_assign_device(
              PCI_BUS(bdf) == bus &&
              PCI_DEVFN2(bdf) == devfn )
         {
+            if ( rmrr->scope.devices_cnt > 1 )
+            {
+                reassign_device_ownership(d, hardware_domain, devfn, pdev);
+                printk(XENLOG_G_ERR VTDPREFIX
+                       " cannot assign any device with RMRR for Dom%d 
(%d)\n",
+                       rmrr->base_address, rmrr->end_address,
+                       d->domain_id, ret);
+                ret = -EPERM;
+                break;
+            }
             ret = rmrr_identity_mapping(d, 1, rmrr, flag);
             if ( ret )
             {

Note this is just one draft code to show our idea. And I'm also 
concerning if we need to introduce a flag to bypass this to make sure we 
still have a approach to our original behavior.
#1.2. Post a design

We'd like to post a preliminary design to Xen community to get a better 
solution.
#2. Phase 2 after 4.6

Once the design is clear we will start writing patches to address this 
completely.
So any idea?

Thanks
Tiejun

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