From: "Michael S. Tsirkin" <mst@redhat.com>
To: open sorcerer <0p3n.s0rc3r3r@gmail.com>
Cc: qemu-devel@nongnu.org, imammedo@redhat.com
Subject: Re: [Qemu-devel] ACPI PCI hotplug table updates
Date: Wed, 3 Oct 2018 14:37:42 -0400 [thread overview]
Message-ID: <20181003143448-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAEJ3UntstF2hsn11MrcoMqb7_JMOxs9GRiALF==S6o2aMpAAeg@mail.gmail.com>
On Wed, Oct 03, 2018 at 10:44:20AM -0700, open sorcerer wrote:
> Hi,
>
> I am digging into an issue where qmp_device_del does not actually delete
> devices when a guest OS is in prelaunch.
What exactly is meant by prelaunch? E.g. is it prelaunch while bios is
doing the pci bus scan?
> This seems to be due to the guest OS
> not handling ACPI events because it is not currently running. If I assume
> correctly, qmp should allow you to add/remove devices while the host is down,
> or if not possible, publish an error message.
>
> I think fixing this issue is as simple as making sure that the VM is in a safe
> state to ignore the hotplug ACPI dance but eject the disk, something like:
>
> prelaunch, preconfig, shutdown: ignore acpi and deal with cleaning devices
> other non-running: bubble up error
> running: default behavior
>
> I was trying to validate that this change would be safe (keep in mind I am
> learning ACPI in little pieces while digging) using GDB, and code inspection.
> While stepping through with GDB i noticed that the PCI slots are controlled by
> memory region and the opaque acpi pci hp state object. I was unable this far to
> find any code executed that modifies the ACPI tables beyond just the pci
> hotplug state.
>
> I also tried to test using "while true; do acpidump | md5; sleep 1; done" in
> the guest OS and then add/remove a virtio-blk-pci device (which exercised the
> ACPI callbacks via piix4 callbacks). The output of the acpidump -> md5 was
> consistent during each phase of the data collection which I believe implied
> that the acpi tables were not modified by the PCI hotplug.
>
> Can someone help me understand:
>
> 1. Are the ACPI tables not modified when doing PCI hotplug?
Yes.
> 2. Do the general changes proposed seem safe?
> 3. Are there resources or documentation I can read to help me understand this
> problem further? I have skimmed through alot of different documents and watched
> some youtube videos, but the ACPI documentation is hard to read and sift
> through and the youtube videos are generally too high level.
>
> Thanks.
>
We are generally trying to move away from ACPI hotplug to native
PCIE hotplug. You can read up on that in the pci express spec.
--
MST
next prev parent reply other threads:[~2018-10-03 18:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-03 17:44 [Qemu-devel] ACPI PCI hotplug table updates open sorcerer
2018-10-03 18:37 ` Michael S. Tsirkin [this message]
2018-10-04 11:57 ` Igor Mammedov
2018-10-04 17:24 ` Michael S. Tsirkin
2018-10-05 8:55 ` Igor Mammedov
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=20181003143448-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=0p3n.s0rc3r3r@gmail.com \
--cc=imammedo@redhat.com \
--cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).