Re: [Xen-devel] First release candidate for 3.2.0

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 12/12/07 13:59, "John Levon" <levon@xxxxxxxxxxxxxxxxx> wrote:

> The first big one, as you say, is our privcmd driver.  We have to decode the
> hypercall and essentially do a copy_from/to_user() on all the buffers passed
> in. The best way to fix this is to do it in userspace: make xc_solaris.c use a
> new ioctl() that passes in buffer address+size information as well as the
> structs themselves. To do this cleanly means pushing a lot of do_domctl() etc.
> into xc_$OS.c, and we just haven't had time - though I'd certainly be
> interested to know how you felt about a change like that.

I'm happy to see OS-specific changes in libxc, and even some restructuring
if absolutely necessary. I'd much rather that than have kernel dependencies
on domctl and sysctl. libxc is not in its current form due to some grand
plan. ;-)

> Number of total physical pages
> 
> - we ask about this for the benefit of our Xen crash dump
>  support. This could easily be a platform op I think?

Would XENMEM_maximum_ram_page be as good or better? If you *really* mean
number of physical RAM pages then we could add that I suppose. How is it
useful?

> Number of real CPUs
> 
> - we use this in our errata checking code. It just seems plain
>  wrong in the Xen case for us to be checking machine errata,
>  but we've never found time to go through them and verify that
>  the hypervisor does the same checks and fixes. If you're
>  interested I list the errata that need this value below.

The TLB flush and C1 ramping errata we have worked around since at least Xen
3.0.2. Erratum 131 should be worked around by the BIOS (in fact, really all
these errata should be worked around by an up-to-date BIOS). If you insist
on fixing up 131 yourselves then you can do it regardless of number of CPUs
-- the manual does not specify that number of CPUs affects this bug, also it
explicitly states that applying the workaround does not affect performance.

> cpu_khz
> 
> - this is an old, old change during bringup which is very
>  possibly fixed; once again, we need to verify we can remove
>  it. As the code says:

I hope it's fixed. If not then you could calibrate the TSC yourself against
the RTC. You know you won't get preempted much during dom0 kernel boot. IRQ
handling is very quick in Xen.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel