All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Cc: Keir Fraser <keir@xen.org>
Subject: Re: [PATCH 2/4] x86/HVM: replace plain numbers
Date: Thu, 22 Jan 2015 14:41:31 +0000	[thread overview]
Message-ID: <54C10C1B.4090801@citrix.com> (raw)
In-Reply-To: <54C10FEF0200007800058295@mail.emea.novell.com>

On 22/01/15 13:57, Jan Beulich wrote:
> ... making the code better document itself. No functional change
> intended.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/hvm/vioapic.c
> +++ b/xen/arch/x86/hvm/vioapic.c
> @@ -53,18 +53,26 @@ static uint32_t vioapic_read_indirect(co
>      switch ( vioapic->ioregsel )
>      {
>      case VIOAPIC_REG_VERSION:
> -        result = ((((VIOAPIC_NUM_PINS-1) & 0xff) << 16)
> -                  | (VIOAPIC_VERSION_ID & 0xff));
> +        result = ((union IO_APIC_reg_01){
> +                  .bits = { .version = VIOAPIC_VERSION_ID,
> +                            .entries = VIOAPIC_NUM_PINS - 1 }
> +                  }).raw;
>          break;
>  
>      case VIOAPIC_REG_APIC_ID:
> +        /*
> +         * Using union IO_APIC_reg_02 for the ID register too, as
> +         * union IO_APIC_reg_00's ID field is 8 bits wide for some reason.
> +         */

Having looked into this, Intel has a 4 bit wide ID with the top 4 bits
reserved, while AMD has the top 4 bits as the Extended ID which may be
used if an appropriate northbridge register has been set.

I think it might be better to use IO_APIC_reg_00 here and mask the write
operations, leaving a note about Intel vs AMD and the fact that emulate
an Intel IOAPIC to match the PIIX3 chipset in Qemu.

Modifying IO_APIC_reg_00 is not appropriate as Xens IOAPIC code needs to
deal with AMD systems as well.

~Andrew

>      case VIOAPIC_REG_ARB_ID:
> -        result = ((vioapic->id & 0xf) << 24);
> +        result = ((union IO_APIC_reg_02){
> +                  .bits = { .arbitration = vioapic->id }
> +                  }).raw;
>          break;
>  
>      default:
>      {
> -        uint32_t redir_index = (vioapic->ioregsel - 0x10) >> 1;
> +        uint32_t redir_index = (vioapic->ioregsel - VIOAPIC_REG_RTE0) >> 1;
>          uint64_t redir_content;
>  
>          if ( redir_index >= VIOAPIC_NUM_PINS )
> @@ -173,7 +181,11 @@ static void vioapic_write_indirect(
>          break;
>  
>      case VIOAPIC_REG_APIC_ID:
> -        vioapic->id = (val >> 24) & 0xf;
> +        /*
> +         * Using union IO_APIC_reg_02 for the ID register, as for some
> +         * reason union IO_APIC_reg_00's ID field is 8 bits wide.
> +         */
> +        vioapic->id = ((union IO_APIC_reg_02){ .raw = val }).bits.arbitration;
>          break;
>  
>      case VIOAPIC_REG_ARB_ID:
> @@ -181,7 +193,7 @@ static void vioapic_write_indirect(
>  
>      default:
>      {
> -        uint32_t redir_index = (vioapic->ioregsel - 0x10) >> 1;
> +        uint32_t redir_index = (vioapic->ioregsel - VIOAPIC_REG_RTE0) >> 1;
>  
>          HVM_DBG_LOG(DBG_LEVEL_IOAPIC, "rte[%02x].%s = %08x",
>                      redir_index, vioapic->ioregsel & 1 ? "hi" : "lo", val);
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -835,7 +835,7 @@ static int vlapic_write(struct vcpu *v, 
>      unsigned int offset = address - vlapic_base_address(vlapic);
>      int rc = X86EMUL_OKAY;
>  
> -    if ( offset != 0xb0 )
> +    if ( offset != APIC_EOI )
>          HVM_DBG_LOG(DBG_LEVEL_VLAPIC,
>                      "offset %#x with length %#lx, and value is %#lx",
>                      offset, len, val);
> --- a/xen/include/asm-x86/hvm/vioapic.h
> +++ b/xen/include/asm-x86/hvm/vioapic.h
> @@ -47,6 +47,7 @@
>  #define VIOAPIC_REG_APIC_ID 0x00 /* x86 IOAPIC only */
>  #define VIOAPIC_REG_VERSION 0x01
>  #define VIOAPIC_REG_ARB_ID  0x02 /* x86 IOAPIC only */
> +#define VIOAPIC_REG_RTE0    0x10
>  
>  struct hvm_vioapic {
>      struct hvm_hw_vioapic hvm_hw_vioapic;
>
>
>

  reply	other threads:[~2015-01-22 14:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-22 13:53 [PATCH 0/4] x86: replace plain numbers Jan Beulich
2015-01-22 13:57 ` [PATCH 1/4] x86/HVM: replace plain number in hvm_combine_hw_exceptions() Jan Beulich
2015-01-22 14:12   ` Andrew Cooper
2015-01-22 14:36     ` Jan Beulich
2015-01-22 14:42   ` Tim Deegan
2015-01-22 15:12     ` Jan Beulich
2015-01-22 15:27       ` Tim Deegan
2015-01-22 13:57 ` [PATCH 2/4] x86/HVM: replace plain numbers Jan Beulich
2015-01-22 14:41   ` Andrew Cooper [this message]
2015-01-22 15:17     ` Jan Beulich
2015-01-23 13:41       ` Andrew Cooper
2015-01-23 13:58         ` Jan Beulich
2015-01-23 13:59           ` Andrew Cooper
2015-01-22 14:00 ` [PATCH 3/4] x86/traps: " Jan Beulich
2015-01-22 14:45   ` Andrew Cooper
2015-01-22 14:01 ` [PATCH 4/4] VMX: " Jan Beulich
2015-01-22 15:21   ` Andrew Cooper
2015-01-23  6:25   ` Tian, Kevin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54C10C1B.4090801@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.