On Tue, Feb 03, 2009 at 04:58:31PM -0200, Glauber Costa wrote:
> >
> > void qemu_system_device_hot_add(int pcibus, int slot, int state)
> > {
> > - qemu_set_irq(pm_state->irq, 1);
> > pci0_status.up = 0;
> > pci0_status.down = 0;
> > if (state)
> > enable_device(&pci0_status, &gpe, slot);
> > else
> > disable_device(&pci0_status, &gpe, slot);
> > - qemu_set_irq(pm_state->irq, 0);
> > +
> > + if (gpe.en & 2) {
> > + qemu_set_irq(pm_state->irq, 1);
> > + qemu_set_irq(pm_state->irq, 0);
> > + }
> > }
>
> Are you sure this works? The trigger is now happening after all the
> events take place. It might well work depending on how qemu exposes
> this, but I have some spare memories of having problems with this in
> the past.
The ACPI code will read the up/down status after the IRQ is triggered
(and nothing will change it, in the meantime). What is your concern?
The OS is responsible for programming the GPE enable bit.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
