Re: [Xen-devel] libxl: vpl011: Fix hex to dec conversion of vuart_gfn in libxl__device_vuart_add

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.10.17 at 14:19, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 13/10/17 13:08, Jan Beulich wrote:
>>>>> On 13.10.17 at 12:44, <bhupinder.thakur@xxxxxxxxxx> wrote:
>>> In libxl__device_vuart_add vuart_gfn is getting stored as a hex value:
>>>
>>>> flexarray_append(ro_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn));
>>> However, xenstore reads this value as a decimal value and tries to map the
>>> wrong address and fails.
>> Is this generic or vuart specific code in xenstore that does so?
>> Could you perhaps simply point me at the consuming side?
>>
>>> Introduced a new format string "PRIu_xen_pfn" which formats the value as a
>>> decimal value.
>> I ask because I'm not really happy about this addition, i.e. I'd
>> prefer the read side to change.
> 
> Can the read side realistically change?

Well, that's why I had asked whether this is generic or specific
code. I would have hoped/assumed that xenstore doesn't
generically try to translate strings into numbers - how would it
know a string is to represent a number in the first place? Hence
I was hoping for this to be specific (and hence) new code.

> Its been decimal for a decade now, and there definitely is 3rd party
> code which uses these values in xenstore (sadly).

Are you trying to tell me there's been a vuart frontend before
the device type introduction in libxl, or is the new device type
compatible with an existing one?

> Then again, the ring-ref key is listed as deprecated in our
> documentation, without any reference describing which key should be used
> instead.  It is also typically a grant reference, not a gfn, so
> something wonky is definitely going on here.

Which put under question how an existing frontend could work
with this new device type.

Jan


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