On Mon, Apr 09, 2018 at 07:40:15AM -0600, Jan Beulich wrote:
>>>> On 09.04.18 at 15:16, <chao....@intel.com> wrote:
>> Given that parsing parameters starts at very early stage in which xmalloc is
>> unusable, I choose to continue using an array other than a list to store 
>> SBDFs
>> of such kind devices, like the way how we manage phantom_devs.
>
>Yes, I was about to say that on v1 when I saw v2 come in.
>
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -1423,6 +1423,16 @@ Defaults to booting secondary processors.
>>  
>>  > Default: `on`
>>  
>> +### pba\_shared\_quirk
>> +> `= List of [<seg>:]<bus>:<device>.<function>`
>> +
>> +Specify a list of SBDF of devices. When assigning devices in this list
>> +to guest, reading or writing the page where MSI-X PBA resides are
>> +allowed. This option provides a workaround for nonstandard PCI devices
>> +whose MSI-X PBA shares the same 4K-byte page with registers irrelevant
>> +to MSI-X. Note that adding an untrusted device to this option would
>> +undermine security of the entire system.
>
>No underscores in new command line options please - use dashes.

Will do.

>
>I'm not convinced though that a global option is well suited here:
>Exposing the device in this way may be okay for one guest, but
>not for another. With your model one would need to reboot the
>entire host for such a usage change.
>
>Furthermore boot time specification of SBDF is a problem with the
>Dom0 kernel possibly re-organizing the topology, and is not going
>to work well with hot-plugged devices.

Point taken. But one concern is if we don't specify devices at boot time
whether PVH dom0 can use such devices (in my understanding, PVH dom0
will use EPT, it will meet the same issue as HVM domU). If not, we need
treat dom0 as an exception; pages where PBA resides won't be marked as
read-only. But mmio_ro_ranges is global. Maybe build two separate
mmio_ro_ranges for dom0 and domU?

Thanks
Chao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Reply via email to