[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v6] x86/hvm: Allow guest_request vm_events coming from userspace



>>> On 25.08.17 at 17:49, <george.dunlap@xxxxxxxxxx> wrote:
> On 08/25/2017 02:44 PM, Jan Beulich wrote:
>>>>> On 25.08.17 at 15:00, <aisaila@xxxxxxxxxxxxxxx> wrote:
>>> On Vi, 2017-08-25 at 06:13 -0600, Jan Beulich wrote:
>>>>>
>>>>>>
>>>>>>>
>>>>>>> On 17.08.17 at 13:50, <aisaila@xxxxxxxxxxxxxxx> wrote:
>>>>> --- a/xen/common/monitor.c
>>>>> +++ b/xen/common/monitor.c
>>>>> @@ -75,6 +75,7 @@ int monitor_domctl(struct domain *d, struct
>>>>> xen_domctl_monitor_op *mop)
>>>>>          domain_pause(d);
>>>>>          d->monitor.guest_request_sync = mop->u.guest_request.sync;
>>>>>          d->monitor.guest_request_enabled = requested_status;
>>>>> +        d->arch.monitor.guest_request_userspace_enabled = mop-
>>>>>> u.guest_request.allow_userspace;
>>>> This breaks the build on ARM.
>>> There are 2 solutions, I can move the case in x86/monitor.c in
>>> the arch_monitor_domctl_event function or I can make a arch specific
>>> function that does the assignment in the x86 case and does nothing in
>>> the arm case. What approach do you prefer?
>> 
>> That's a question to the maintainers of that code. What I care
>> about is that patches touching common code please are at least
>> build-checked on the other architecture before submission.
> 
> I don't think this is a reasonable requirement.  That's what push gates
> (and Travis) are for.

Hmm, I can see your way of thinking, but to me (doing an ARM
build test if I don't forget it before pushing) it's a waste of time
to apply a patch only to then find it breaks the build and needs
reverting.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.