RE: [PATCH] enable port accesses with (almost) fullregister context

RE: [PATCH] enable port accesses with (almost) fullregister context

[Tian, Kevin]

>From: Keir Fraser
>Sent: 2006年9月11日 9:19
>Would it be cleaner to allow dom0 to have really direct access to some
>I/O
>ports by allowing it to set a real I/O bitmap? I implemented I/O bitmaps
>via
>emulation mainly because it makes context switching faster and it is less
>of
>a pain to keep admin and guest bitmasks in sync if they are checked
>synchronously. But a direct dom0-only bitmap would be a bit easier:
>quick to
>turn on/off and no need to sync with admin bitmaps. Main downside is
>that
>it'll slow down context-switch paths a little bit.
>
> -- Keir
>

Hi, Keir,
	Say in the driver domain case, does dom0-only bitmap need to sync with admin bitmaps? Or simply depend on the assumption that dom0 won't use io ports granted to other domains?

Thanks,
Kevin

Re: [PATCH] enable port accesses with (almost) fullregister context

[Keir Fraser]

On 11/9/06 6:24 pm, "Tian, Kevin" <kevin.tian@intel.com> wrote:

> Hi, Keir,
> Say in the driver domain case, does dom0-only bitmap need to sync with admin
> bitmaps? Or simply depend on the assumption that dom0 won't use io ports
> granted to other domains?

There's no checking of that kind of thing already. Xen will happily allow
I/O memory and I/O ports to be assigned write access for multiple domains
simultaneously. It's up to control tools, or a sysadmin, to implement or
enforce a more sophisticated policy if that is what is wanted.

 -- Keir

Re: [PATCH] enable port accesses with (almost) fullregister context

[Keir Fraser]

On 11/9/06 8:58 pm, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk> wrote:

> On 11/9/06 6:24 pm, "Tian, Kevin" <kevin.tian@intel.com> wrote:
> 
>> Hi, Keir,
>> Say in the driver domain case, does dom0-only bitmap need to sync with admin
>> bitmaps? Or simply depend on the assumption that dom0 won't use io ports
>> granted to other domains?
> 
> There's no checking of that kind of thing already. Xen will happily allow
> I/O memory and I/O ports to be assigned write access for multiple domains
> simultaneously. It's up to control tools, or a sysadmin, to implement or
> enforce a more sophisticated policy if that is what is wanted.

Maybe I misunderstood the question. If control tools update an admin bitmap
today, then future port accesses by the guest are affected. If this dom0
special bitmap is implemented, it is probably the case that we will not
filter it through dom0's admin bitmap. As you say, we'll assume that special
ports wouldn't be assigned to other domU's anyway.

 -- Keir

RE: [PATCH] enable port accesses with (almost) fullregister context

[Tian, Kevin]

>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk]
>Sent: 2006年9月11日 13:05
>>
>>> Hi, Keir,
>>> Say in the driver domain case, does dom0-only bitmap need to sync
>with admin
>>> bitmaps? Or simply depend on the assumption that dom0 won't use io
>ports
>>> granted to other domains?
>>
>> There's no checking of that kind of thing already. Xen will happily allow
>> I/O memory and I/O ports to be assigned write access for multiple
>domains
>> simultaneously. It's up to control tools, or a sysadmin, to implement or
>> enforce a more sophisticated policy if that is what is wanted.
>
>Maybe I misunderstood the question. If control tools update an admin
>bitmap
>today, then future port accesses by the guest are affected. If this dom0
>special bitmap is implemented, it is probably the case that we will not
>filter it through dom0's admin bitmap. As you say, we'll assume that
>special
>ports wouldn't be assigned to other domU's anyway.
>
> -- Keir

Yes, this assumption can ensure minimal performance affect. But, say in any case you still need to sync this special dom0 bitmap with guest bitmap, how much extra overhead to pay syncing with admin bitmap too? If not obviously differ, filtering all bitmaps can provide a more flexible interface for port assignment. :-)

Thanks,
Kevin