On 2015/5/28 15:55, Jan Beulich wrote:
On 28.05.15 at 07:48, wrote:
On 2015/5/22 17:46, Jan Beulich wrote:
On 22.05.15 at 11:35, 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
>>> On 28.05.15 at 07:48, wrote:
> On 2015/5/22 17:46, Jan Beulich wrote:
> On 22.05.15 at 11:35, 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?
>>
On 2015/5/22 17:46, Jan Beulich wrote:
On 22.05.15 at 11:35, 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 th
>>> On 22.05.15 at 11:35, 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 -
v2:
* Instead of that fixed predefined rdm memory boundary, we'd like to
introduce a parameter, "rdm_mem_boundary", to set this threshold value.
* Remove that existing USB hack.
* Make sure the MMIO regions all fit in the available resource window
* Rename our policy, "force/try" -> "strict/r
