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

Re: [Xen-devel] [PATCH] tools/libxl: Fix build following c/s 74fd984ae


On 09/04/18 12:07, Wei Liu wrote:
On Mon, Apr 09, 2018 at 11:29:28AM +0100, Julien Grall wrote:

On 06/04/18 10:33, Wei Liu wrote:
On Fri, Apr 06, 2018 at 10:03:14AM +0100, Julien Grall wrote:
This is wrong. gicv_to_string works on XEN_DOMCTL_* define and not the 
So this will not give the right output.

I would suggest to revert that patch and I will send one that actually fix the 
Not sure I would be able to do it today thought.

OK, I will revert this patch.

I have looked at a potential way to fix it. The original patch (74fd984ae6)
assumption is incorrect. Some of information from xc_domain_configuration_t
is not written back ton libxl__domain_build_state.

For instance, this is the case of the clock frequency. That field is used to
workaround bootloader/firmware that didn't configure correct CNTFRQ. If we
detect such platform, we will read the host clock frequency from the host
Device-Tree and write it to the guest Device-Tree. This should never be
exposed to the guest.

Not sure I follow. If you write that value to guest DT, guest should be
able to see it?

On normal system the clock frequency can be read by using the system register CNTFRQ. This register is usually initialized by the firmware/bootloader. However, on some platforms the firmware does not do its job and therefore CNTFRQ is configured incorrectly. To workaround the problem, a property exists in the host DT with the correct frequency.

On the broken platform, the field clock_frequency in xc_domain_configuration_t will be written by the hypervisor with the correct frequency.

Arguably, this field should not belong to xc_domain_configuration_t. So I
can see two solutions:
        1) Store the frequency in libxl__domain_build_state
        2) Introduce a different hypercall to get the system frequency. I guess 
could piggy-back on Andrew's idea to provide

The latter will require some rework in the code and define a new API. Not
sure if that would be acceptable for Xen 4.11.

Any opinions?

#1 seems simpler to me, especially since we already have vuart (ARM
only) information in libxl__domain_build_state.

I will have a look at that.


Julien Grall

Xen-devel mailing list



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