[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] tools/libxl: Fix build following c/s 74fd984ae
Hi, On 09/04/18 12:07, Wei Liu wrote: On Mon, Apr 09, 2018 at 11:29:28AM +0100, Julien Grall wrote:Hi, 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 LIBXL_GIC_*. So this will not give the right output. I would suggest to revert that patch and I will send one that actually fix the compilation. 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 we could piggy-back on Andrew's idea to provide XEN_DOMCTL_{get,set}_arch_settings. 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. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |