[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 08/15] pvh/acpi: Handle ACPI accesses for PVH guests
On 12/06/2016 09:34 AM, Jan Beulich wrote: >>>> On 29.11.16 at 16:33, <boris.ostrovsky@xxxxxxxxxx> wrote: >> +static int acpi_access_common(struct domain *d, >> + int dir, unsigned int port, >> + unsigned int bytes, uint32_t *val) >> +{ > Why is this a separate function instead of the body of > acpi_guest_access()? Do you mean to later use this for the > domctl handling (as the use of XEN_DOMCTL_ACPI_* suggests)? > Such things may be worthwhile mentioning at least after the first > --- marker. Yes, this becomes common code with the subsequent patch. I'll note this in the commit message. >> --- a/xen/common/domctl.c >> +++ b/xen/common/domctl.c >> @@ -651,6 +651,11 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) >> u_domctl) >> goto maxvcpu_out; >> } >> >> + d->avail_vcpus = xzalloc_array(unsigned long, >> + BITS_TO_LONGS(d->max_vcpus)); >> + if ( !d->avail_vcpus ) >> + goto maxvcpu_out; > Considering this isn't being touched outside of > acpi_access_common(), how come you get away without setting > the bits for the vCPU-s online when the guest starts? The AML code, which is the only reader of the map, is only executed after the map has been updated (i.e. the SCI has been sent). But I probably should have the toolstack initialize it when building the guest. -boris _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |