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

Re: [PATCH V5 1/3] xen/arm: Introduce gpaddr_bits field to struct xen_arch_domainconfig

  • To: Oleksandr <olekstysh@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 7 Oct 2021 14:43:08 +0200
  • 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ads2pLpEmPIshtguItxijndEtuL6sIznRl/P3HMXu0M=; b=XZJcWXppwLFtO/s/EL5uv7O+R5IL8HG1UThFhKuw/TppuP5Lg84POT+VzNDpNmSdDXSVCAuGCana6HcZNzjJBH+3EFNpzEI2SwFWPyoLUiEy5v2dkA1VGGTZJT4hW8y4cveD6jOEn8IdBirA11TyUNclraG5HezL9rO/luT5NoRjF/dALdC+oTNhaArLtRlTYu4R9OIB6cpLdgxUXC/eIeHYNUT8uQYgKZtsobTvfoeJ2V0dHBi5lBOQoxYRdg02nOFq05WhpP7IRbQuXin4OTm6GOpcXvfAodxhFuFpMUz0MxA7/D7SG787QyGjJzTlEBLMS0Oz4H9VyOv9vCaw2A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cJdq3aTAqJQDaCp9ng1KJifpJEVPf7V//AdWapPYiyDN03vXKrrgjw66riDnh5sxfvg1TKNxKiozmZBTZrsHOLPXMp9N4wx7fby+waKby92YQdizDarLNfzU8EkT0Ap4ZoU8QypVC8liA+KRFbHohwS29ur4lGXrKfZhuhGWxEOSG999+P2rNQwT4bRsYNnaKxKnihtLaTtwz2KVcuNF9wU3bq8KdZY35FzW1DtVygnZNfLvWLDYnoqRc9zgirspGG53B1ROzPWYnXT5pqxQM0+jor5lEZlU064L+gZmAyZyucHjWWZCBNIGcIujucJLMAiLKzhpboWRZ98e/ik+OA==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 07 Oct 2021 12:43:24 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 07.10.2021 14:30, Oleksandr wrote:
> On 07.10.21 10:42, Jan Beulich wrote:
>> On 06.10.2021 13:22, Oleksandr Tyshchenko wrote:
>>> Changes V4 -> V5:
>>>     - update patch subject and description
>>>     - drop Michal's R-b
>>>     - pass gpaddr_bits via createdomain domctl
>>>       (struct xen_arch_domainconfig)
>> I'm afraid I can't bring this in line with ...
>>> --- a/xen/include/public/arch-arm.h
>>> +++ b/xen/include/public/arch-arm.h
>>> @@ -333,6 +333,11 @@ struct xen_arch_domainconfig {
>>>        *
>>>        */
>>>       uint32_t clock_frequency;
>>> +    /*
>>> +     * OUT
>>> +     * Guest physical address space size
>>> +     */
>>> +    uint8_t gpaddr_bits;
>> ... this being an OUT field. Is this really what Andrew had asked for?
>> I would have expected the entire struct to be IN (and the comment at
>> the top of the containing struct in public/domctl.h also suggests so,
>> i.e. your new field renders that comment stale). gic_version being
>> IN/OUT is already somewhat in conflict ...
> I am sorry but I'm totally confused now, we want the Xen to provide 
> gpaddr_bits to the toolstack, but not the other way around.
> As I understand the main ask was to switch to domctl for which I wanted 
> to get some clarification on how it would look like... Well, this patch 
> switches to use
> domctl, and I think exactly as it was suggested at [1] in case if a 
> common one is a difficult to achieve. I have to admit, I felt it was 
> indeed difficult to achieve.

Sadly the mail you reference isn't the one I was referring to. It's not
even from Andrew. Unfortunately I also can't seem to be able to locate
this, i.e. I'm now wondering whether this was under a different subject.
Julien, in any event, confirmed in a recent reply on this thread that
there was such a mail (otherwise I would have started wondering whether
the request was made on irc). In any case it is _that_ mail that would
need going through again.

> I thought that a comment for struct xen_domctl_createdomain in 
> public/domctl.h was rather related to the struct fields described in the 
> public header than to the arch sub-struct internals described elsewhere. 
> But if my assumption is incorrect, then yes the comment got stale and 
> probably not by changes in current patch, but after adding 
> clock_frequency field (OUT). If so we can add a comment on top of arch 
> field clarifying that internal fields *might* be OUT.
>> One of the problems with
>> _any_ of the fields being OUT is that then it is unclear how the output
>> is intended to be propagated to consumers other than the entity
>> creating the domain.
> If I *properly* understood your concern, we could hide that field in 
> struct libxl__domain_build_state and not expose it to struct 
> libxl_domain_build_info. Shall I?

I'm afraid I'm lost: I didn't talk about the tool stack at all. While
"consumer" generally means the tool stack, the remark was of more
abstract nature.


> [1] 
> https://lore.kernel.org/xen-devel/093bc1d5-bf6a-da0a-78b5-7a8dd471a063@xxxxxxxxx/



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