qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).