should ioapic_service really be modelling cpu writes?

["Alex Bennée" <alex.bennee@linaro.org>]

Hi,

I've been trying to remove current_cpu hacks from our hw/ emulation and
replace them with an explicit cpu_index derived from MemTxAttrs. So far
this has been going mostly ok but I've run into problems on x86 due to
the way the apic/ioapic are modelled. It comes down to the function
ioapic_service() which eventually does:

   /* No matter whether IR is enabled, we translate
    * the IOAPIC message into a MSI one, and its
    * address space will decide whether we need a
    * translation. */
   stl_le_phys(ioapic_as, info.addr, info.data);

Which essentially calls the memory API to simulate a memory write.
However to generate a properly formed MemTxAttrs we need to know what
CPU we are running on. In the case of ioapic_service() we may well be in
the main thread either for an expiring timer:

 hpet_timer->qemu_set_irq->ioapic_set_irq

or for reset handling:

 pc_machine_reset->hpet_reset->qemu_set_irq->ioapic_set_irq

neither of which can get a associated CPU. I assume if the actual writes
are triggered we never actually actioned stuff because we had:

  DeviceState *cpu_get_current_apic(void)
  {
      if (current_cpu) {
          X86CPU *cpu = X86_CPU(current_cpu);
          return cpu->apic_state;
      } else {
          return NULL;
      }
  }

which basically causes the updates to be dropped on the floor. However
during the conversion I went with something like:

  if (attrs.requester_type != MTRT_CPU) {
      return MEMTX_ACCESS_ERROR;
  }
  dev = cpu_get_current_apic(attrs.requester_id);

but that breaks current behaviour. It makes me wonder if the modelling
of the APIC is really representative of what the real HW does or if the
memory writes are simply a shortcut that happens to work?

-- 
Alex Bennée