Re: [Xen-devel] Re: [PATCH] xen: Pack some hvmop memory structur

>>> On 04.02.11 at 17:30, Tim Deegan <Tim.Deegan@xxxxxxxxxx> wrote:
> At 16:24 +0000 on 04 Feb (1296836660), Paolo Bonzini wrote:
>> Am I missing something glaring, or this is breaking the ABI between 
>> hypervisor and kernels?
> 
> It only breaks the ABI between xen and tools, which are supposed always
> to be version-matched.  I'm not sure that it's particularly worthwhile

According to x86's do_hvm_op() I would say a HVM guest can issue
HVMOP_set_mem_type for itself. Is that perhaps a mistake?

Similarly, HVMOP_[gs]et_mem_access bail on
current->domain->domain_id == a.domid, but
rcu_lock_target_domain_by_id() happily accepts DOMID_SELF
without any further checks. At least for the "set" variant this
very much looks like a mistake to me.

> though - at first glance it's saving about ten bytes of argument space.
> Unless these operations are happening in large batches?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread]

Current Thread

[Next in Thread>

Previous by Date:

Re: [Xen-devel] Re: [PATCH] xen: Pack some hvmop memory structures better, Tim Deegan

Next by Date:

Re: [Xen-devel] [PATCH] set mtu from bridge also on vif interface, Olaf Hering

Previous by Thread:

Re: [Xen-devel] Re: [PATCH] xen: Pack some hvmop memory structures better, Tim Deegan

Next by Thread:

[Xen-devel] [PATCH] kdump: introduce "reset_devices" command line option, Olaf Hering

Indexes:

[Date] [Thread] [Top] [All Lists]