[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH 1/4] xen/spinlocks: in debug builds store cpu holding the lock
- To: Juergen Gross <JGross@xxxxxxxx>
- From: Jan Beulich <JBeulich@xxxxxxxx>
- Date: Thu, 8 Aug 2019 12:18:06 +0000
- Accept-language: en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=suse.com;dmarc=pass action=none header.from=suse.com;dkim=pass header.d=suse.com;arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HnYQmOb4uWqqVpgCMhNJbZiy5TMGunhqoBd6rVg9J2s=; b=YNwtCIxpEAuOWw31zrPPVbRjaVgrmLbJI5KM2EiDtXnPj0ofkvE63z/DJwHAnNvF1QxL6jDm64Hqv54zIOvYWFKms92M4HjQg+w7M/uJRXEydL1E/5Lv86Oz9sm2MWT4bKDV8TuYEXVAjVoTB+RZyDy9QcU44H2Vfj80Dz8ic6BuYSYMCYGgKcNul8QNnQom0nUVIrY/UkCNIX3JJKDGfwqMn/fqX6MmX9Rnjf58kGYc2RszS83CMxOfIOcl9ApndMt7/aryYhLKAV9gSIo9OPcUjVoocwDNADS4fXuRF1imPnZdzSBydunveSCxgHQn0Y7zzg8h7k8X62L7a/TN7w==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KNXBrHkFiunIYbd8tBfDXpP9gP+z2xPX9kbqlRWvGc5JpsKYnAnl7Duub6+uaXPnmlNbLiy+SZ8NaTgViD0HUFQxfQ62h5uqH884ai0ih5PW8/bp9ObbQfFGu7FpaqBtxwOJIxx+nGf0ZlBkqOWFAZTrrOK2LDVERV3ZbbcvCBY1ZKru0bKaD1hfZRqFDBq0BQeZzHcGtZ7cKGxlOMBNSE4+1P+6FRwOkELUiNYyf+ZbMxrCovrgzXaxIXzWiWqtwSxC7v76oRgjCjiKpjc9pdlq/LLCjPavwoYFxnbhqtfacTFhPxq2d9+ZcsMBYTlP58gPV9HBFgdA1Wro+vBmxA==
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=JBeulich@xxxxxxxx;
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Thu, 08 Aug 2019 12:22:25 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHVTSzXlrQ8kurvmUW1rudnDuQmCKbw9GCA///tid6AACvj3YAAF72XgAAGxIA=
- Thread-topic: [PATCH 1/4] xen/spinlocks: in debug builds store cpu holding the lock
On 08.08.2019 13:53, Juergen Gross wrote:
> On 08.08.19 12:28, Julien Grall wrote:
>> On 08/08/2019 08:51, Juergen Gross wrote:
>>> On 08.08.19 08:58, Jan Beulich wrote:
>>>> On 07.08.2019 16:31, Juergen Gross wrote:
>>>> Do we have an implied assumption somewhere that unsigned short is
>>>> exactly 16 bits wide? I think "val" wants to be uint16_t here (as
>>>> you really mean "exactly 16 bits"), the two boolean fields want
>>>> to be bool, and the remaining two ones unsigned int.
>>>
>>> But that would increase the size of the union to 4 bytes instead of 2.
>>> So at least pad and cpu must be unsigned short or (better) uint16_t.
>>
>> How about bool irq_safe:1?
>
> I didn't question that, but OTOH I'm not sure doing something like:
>
> struct {
> bool unseen:1;
> bool irq_safe:1;
> uint16_t pad:2;
> uint16_t cpu:12;
> }
>
> is guaranteed to be 2 bytes long. I think pad will be still put into the
> first byte, but the compiler might decide that the 4 bits left won't be
> able to hold the next 12 bits so it could start a new uint16_t at offset
> 2.
>
> Moving the bool types to the end of the struct would avoid that IMHO.
Moving the two bool-s further down will also simplify extraction and
insertion of the "cpu" field.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
