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

Re: [Xen-devel] [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests



>>> On 09.11.16 at 15:39, <boris.ostrovsky@xxxxxxxxxx> wrote:
> @@ -244,7 +245,8 @@ int main(int argc, char **argv)
>  #endif
>  
>      /* Operation Region 'PRST': bitmask of online CPUs. */
> -    stmt("OperationRegion", "PRST, SystemIO, 0xaf00, 32");
> +    stmt("OperationRegion", "PRST, SystemIO, 0x%x, %d",

%#x

> --- a/tools/libacpi/static_tables.c
> +++ b/tools/libacpi/static_tables.c
> @@ -20,6 +20,8 @@
>   * Firmware ACPI Control Structure (FACS).
>   */
>  
> +#define ACPI_REG_BIT_OFFSET    0

Can you completely exclude us ever wanting to support something
that's not on a byte boundary? I think there was a good reason ...

> @@ -30,14 +32,6 @@ struct acpi_20_facs Facs = {
>  /*
>   * Fixed ACPI Description Table (FADT).
>   */
> -
> -#define ACPI_PM1A_EVT_BLK_BIT_WIDTH         0x20
> -#define ACPI_PM1A_EVT_BLK_BIT_OFFSET        0x00
> -#define ACPI_PM1A_CNT_BLK_BIT_WIDTH         0x10
> -#define ACPI_PM1A_CNT_BLK_BIT_OFFSET        0x00
> -#define ACPI_PM_TMR_BLK_BIT_WIDTH           0x20
> -#define ACPI_PM_TMR_BLK_BIT_OFFSET          0x00

... these specified both width and offset.

> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -87,6 +87,12 @@ struct hvm_domain {
>      } ioreq_server;
>      struct hvm_ioreq_server *default_ioreq_server;
>  
> +    /* PVH guests */
> +    struct {
> +        uint8_t pm1a[ACPI_PM1A_EVT_BLK_LEN];
> +        uint8_t gpe[ACPI_GPE0_BLK_LEN_V1];
> +    } acpi_io;

This is left unused in this patch - please add it once it gets used.

> --- a/xen/include/public/hvm/ioreq.h
> +++ b/xen/include/public/hvm/ioreq.h
> @@ -24,6 +24,8 @@
>  #ifndef _IOREQ_H_
>  #define _IOREQ_H_
>  
> +#include "hvm_info_table.h" /* HVM_MAX_VCPUS */
> +
>  #define IOREQ_READ      1
>  #define IOREQ_WRITE     0
>  
> @@ -124,6 +126,17 @@ typedef struct buffered_iopage buffered_iopage_t;
>  #define ACPI_GPE0_BLK_ADDRESS        ACPI_GPE0_BLK_ADDRESS_V0
>  #define ACPI_GPE0_BLK_LEN            ACPI_GPE0_BLK_LEN_V0
>  
> +#define ACPI_PM1A_EVT_BLK_LEN        0x04
> +#define ACPI_PM1A_CNT_BLK_LEN        0x02
> +#define ACPI_PM_TMR_BLK_LEN          0x04

Just like ACPI_GPE0_BLK_LEN these should really go next to their
address definitions. Provided we really want to hard code further
values here in the first place, which I don't think we should. The
goal should rather be for all these hard coded values to go away
(which really should have happened when the V1 variants had
been added).

> +/* Location of online VCPU bitmap. */
> +#define ACPI_CPU_MAP                 0xaf00
> +#define ACPI_CPU_MAP_LEN             ((HVM_MAX_VCPUS / 8) + \
> +                                      ((HVM_MAX_VCPUS & 7) ? 1 : 0))

((HVM_MAX_VCPUS + 7) / 8)

But as indicated elsewhere, this should be made less static anyway.

Also, no matter that there are (many, or should I say only) bad
examples in this file, please don't add new possible name space
conflicts: Any new constants should start with XEN_.

Jan


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

 


Rackspace

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