This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH 1/3] xen: pvhvm: allow user to request no emu

To: Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 1/3] xen: pvhvm: allow user to request no emulated device unplug
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Thu, 19 Aug 2010 09:44:27 -0700
Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Thu, 19 Aug 2010 09:45:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1282235659.3731.37.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1282211932.3170.2341.camel@xxxxxxxxxxxxxxxxxxxxxx> <1282211946-8629-1-git-send-email-ian.campbell@xxxxxxxxxx> <alpine.DEB.2.00.1008191132250.2545@kaball-desktop> <1282215007.3170.2449.camel@xxxxxxxxxxxxxxxxxxxxxx> <1282215140.3170.2454.camel@xxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1008191153300.2545@kaball-desktop> <4C6D577F.6020607@xxxxxxxx> <1282235659.3731.37.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.1
 On 08/19/2010 09:34 AM, Gianni Tedesco wrote:
> On Thu, 2010-08-19 at 17:10 +0100, Jeremy Fitzhardinge wrote:
>> On 08/19/2010 03:54 AM, Stefano Stabellini wrote:
>>> On Thu, 19 Aug 2010, Ian Campbell wrote:
>>>> On Thu, 2010-08-19 at 11:50 +0100, Ian Campbell wrote:
>>>>> On Thu, 2010-08-19 at 11:37 +0100, Stefano Stabellini wrote:
>>>>>> On Thu, 19 Aug 2010, Ian Campbell wrote:
>>>>>>>         if (r && !(r == XEN_PLATFORM_ERR_MAGIC &&
>>>>>>> +                       (xen_emul_unplug != -1) &&
>>>>>>>                         (xen_emul_unplug & XEN_UNPLUG_IGNORE)))
>>>>>> I wouldn't add xen_emul_unplug != -1 because it should be clear that
>>>>>> xen_emul_unplug & XEN_UNPLUG_IGNORE always implies xen_emul_unplug != -1.
>>>>> That's not correct since -1 is all 1s. So you can get a false positive
>>>>> for "xen_emul_unplug & XEN_UNPLUG_IGNORE" if xen_emul_unplug == -1.
>>>> IOW if we were to rewrite the test to use less boolean logic the patch
>>>> might look like:
>>>>    if (r) {
>>>>            if (r != XEN_PLATFORM_ERR_MAGIC)
>>>>                    return;
>>>> +          if (xen_emul_unplug == -1)
>>>> +                  return;
>>>>            if (!(xen_emul_unplug & XEN_UNPLUG_IGNORE))
>>>>                    return;
>>>>    }
>>>> Perhaps this refactoring is worthwhile in any case? It certainly makes
>>>> my head hurt less ;-)
>>> Yeah, it is probably worth it anyway :)
>> Treating a variable as an integer and a bitfield seems like a bad idea.
> Should be fine? I'd just #define XEN_UNPLUG_ALL_THE_BITS ~0U for the
> sake of cosmetics...

In a bitfield the bits are typically independent, whereas in an integer
you interpret all the bits to get a value.  Making "all bits set" mean
something other than all the bitfield bits are set is just asking for
something bad to happen to you.

Why not define a bit to mean whatever "-1" currently means?


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>