qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] KVM call agenda for 2013-05-28


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] KVM call agenda for 2013-05-28
Date: Wed, 29 May 2013 19:19:31 +0300

On Wed, May 29, 2013 at 11:12:06AM -0500, Anthony Liguori wrote:
> "Michael S. Tsirkin" <address@hidden> writes:
> 
> > On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
> >> On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
> >> > Juan is not available now, and Anthony asked for
> >> > agenda to be sent early.
> >> > So here comes:
> >> > 
> >> > Agenda for the meeting Tue, May 28:
> >> > 
> >> > - Generating acpi tables
> >> 
> >> I didn't see any meeting notes, but I thought it would be worthwhile
> >> to summarize the call.  This is from memory so correct me if I got
> >> anything wrong.
> >> 
> >> Anthony believes that the generation of ACPI tables is the task of the
> >> firmware.  Reasons cited include security implications of running more
> >> code in qemu vs the guest context, complexities in running iasl on
> >> big-endian machines, possible complexity of having to regenerate
> >> tables on a vm reboot, overall sloppiness of doing it in QEMU.  Raised
> >> that QOM interface should be sufficient.
> >> 
> >> Kevin believes that the bios table code should be moved up into QEMU.
> >> Reasons cited include the churn rate in SeaBIOS for this QEMU feature
> >> (15-20% of all SeaBIOS commits since integrating with QEMU have been
> >> for bios tables; 20% of SeaBIOS commits in last year), complexity of
> >> trying to pass all the content needed to generate the tables (eg,
> >> device details, power tree, irq routing), complexity of scheduling
> >> changes across different repos and synchronizing their rollout,
> >> complexity of implemeting the code in both OVMF and SeaBIOS.  Kevin
> >> wasn't aware of a requirement to regenerate acpi tables on a vm
> >> reboot.
> >
> > I think this last one is based on a misunderstanding: it's based
> > on assumption that we we change hardware by hotplug
> > we should regenerate the tables to match.
> > But there's no management that can take advantage of
> > this.
> > Two possible reasonable things we can tell management:
> > - hotplug for device XXX is not supported: restart qemu
> >   to make guest use the device
> > - hotplug for device XXX is supported
> 
> This introduces an assumption: that the device model never radically
> changes across resets.
> 
> Why should this be true?  Shouldn't we be allowed to increase the amount
> of memory the guest has across reboots?  That's equivalent to adding
> another DIMM after power off.
> 

You can argue the same thing about non hotpluggable devices:
you might be able to replace them when guest is powered off.

It's not supported ATM and if/when it is, there's a bunch of
code to be written.

> Not generating tables on reset does limit what we can do in a pretty
> fundamental way.  Even if you can argue it in the short term, I don't
> think it's viable in the long term.
> 
> Regards,
> 
> Anthony Liguori

No because that's not "at reset".
We need a separate state for power off.

You power off the machine, add DIMM, restart it.

Its not something you can do from inside the guest,
unlike reset.

At the moment, the only way to implement this is by
exiting from QEMU.
So we are not introducing any regressions here.
When qemu gains power off state we can add a handler
and regenerate the tables.

-- 
MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]