qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Marcel Apfelbaum <marcel@redhat.com>
To: Alexander Bezzubikov <zuban32s@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
	ehabkost@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org,
	rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH RFC 0/6] q35: add acpi pci hotplug support
Date: Tue, 4 Jul 2017 15:18:29 +0300	[thread overview]
Message-ID: <6f9d9521-88c3-715d-e60f-d36d8314e5da@redhat.com> (raw)
In-Reply-To: <CAKSfGUA9Fmk5Z0RpQKRi8oKBQd8FYdMbEiJifWSDhKJagjtd5A@mail.gmail.com>

On 04/07/2017 4:00, Alexander Bezzubikov wrote:
> That is why I think we can consider a possibility of forgetting about 
> ACPI hot plug in pcie-pci bridge and use only SHPC (with some correcting 
> work). Especially since q35 is used only for 'modern' Windows guests and 
> there're no big problems with SHPC on Linux guests.

Hi Alexandr,

Sure, SHPC is certainly enough, and Windows7+ guests support
is also enough.
Patches for a hot-pluggable pcie-pci bridge supporting SHPC based
hot-plug/hot-unplug are welcome :) .

One last thing, please avoid top-posting...

Thanks,
Marcel

> 
> вт, 4 июля 2017 г. в 1:06, Alexander Bezzubikov <zuban32s@gmail.com 
> <mailto:zuban32s@gmail.com>>:
> 
>     Tried it on Win7 Enterprise SP1 - SHPC works well,  _OSC patches
>     aren't necessary (since pci-bridge has its own controller, I suppose).
>     On Linux guests it works when adding device from CLI with -device,
>     but OS seems to fail detecting the device when I add it with
>     device_add from monitor.
>     Also there're some issues with unplugging on Linux (haven't tested
>     unplugging on WIndows yet). That's the news.
> 
>     2017-07-03 21:29 GMT+03:00 Michael S. Tsirkin <mst@redhat.com
>     <mailto:mst@redhat.com>>:
> 
>         On Mon, Jul 03, 2017 at 09:26:33PM +0300, Marcel Apfelbaum wrote:
>          > On 03/07/2017 19:34, Michael S. Tsirkin wrote:
>          > > On Mon, Jul 03, 2017 at 02:27:11PM +0200, Igor Mammedov wrote:
>          > > > On Fri, 30 Jun 2017 10:25:05 +0300
>          > > > Marcel Apfelbaum <marcel@redhat.com
>         <mailto:marcel@redhat.com>> wrote:
>          > > >
>          > > > [...]
>          > > > >
>          > > > > So for the modern systems not supporting PCI ACPI hotplug
>          > > > > we don't need pci-bridges anyway, but for the older ones
>          > > > > the ACPI code of the pci-bridge will be loaded into the
>          > > > > ACPI namespace only if a pci-bridge is actually
>         hot-plugged.
>          > > >
>          > > > just note that the set of 'older' guest OSes is limited to
>          > > > one that do not support SHPC (i.e. to EOLed WinXP & co)
>          > > > as for linux and more modern Windows SHPC hotplug should
>          > > > just work without our ACPI hack (which taxes low memory
>          > > > to keep acpi tables for bridges).
>          > > >
>          > > > So I'm in favor of Michael's suggestion to leave ACPI PCI
>          > > > only in PC machine for old WinXP guests and to keep Q35
>          > > > clean, where linux or newer Windows guests could just
>          > > > use standard SHPC.
>          > > >
>          > > > [...]
>          > >
>          > > I didn't realize windows actually supports SHPC for PCI.
>          >
>          > Me neither, if Igor is right I am all for shpc hotplug
>          > since Q35 is not supposed to support older guests.
>          >
>          > I remember I succeeded to enable shpc hotplug some time
>          > ago, but only for Linux guests.
>          >
>          > Igor, do you have some spec/doc on newer Windows OSes that
>         confirm
>          > PCI shpc hotplug support?
> 
>         Just try it, easier than poking at specs which aren't always up
>         to date.
> 
>         > >
>         > > Do they correctly set _OSC Arg3, bit offset 1?
>         > >     SHPC Native Hot Plug control
>         > >     The OS sets this bit to 1 to request control over PCI/PCI-X Standard Hot-Plug Controller
>         > >     (SHPC) hot plug. If the OS successfully receives control of this feature, it must track and
>         > >     update the status of hot plug slots and handle hot plug events as described in the SHPC
>         > >     Specification.
>         > > I was under impression they only set bit 0.
>         > >
>         >
>         > Alexandr, if modern Windows OSes do support shpc, it makes our
>         > job easier, can you please try to enable shpc hotplug?
>         >
>         > Thanks,
>         > Marcel
> 
>         No need to enable or even have a bridge for that at all -
>         set the bit in _OSC, see what does guest enable.
> 
> 
> 
> 
>     -- 
>     Alexander Bezzubikov
> 
> -- 
> Alexander Bezzubikov

  reply	other threads:[~2017-07-04 12:18 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-29 21:55 [Qemu-devel] [PATCH RFC 0/6] q35: add acpi pci hotplug support Aleksandr Bezzubikov
2017-06-29 21:55 ` [Qemu-devel] [PATCH RFC 1/6] hw/acpi: remove dead acpi code Aleksandr Bezzubikov
2017-06-29 23:27   ` Michael S. Tsirkin
2017-07-03 11:52     ` Igor Mammedov
2017-06-29 21:55 ` [Qemu-devel] [PATCH RFC 2/6] hw/acpi: simplify dsdt building code Aleksandr Bezzubikov
2017-06-29 21:55 ` [Qemu-devel] [PATCH RFC 3/6] hw/acpi: fix pcihp io initialization Aleksandr Bezzubikov
2017-06-29 23:22   ` Michael S. Tsirkin
2017-06-29 21:56 ` [Qemu-devel] [PATCH RFC 4/6] hw/acpi: prepare pci hotplug IO for ich9 Aleksandr Bezzubikov
2017-06-29 23:28   ` Michael S. Tsirkin
2017-06-29 21:56 ` [Qemu-devel] [PATCH RFC 5/6] hw/acpi: extend acpi pci hotplug support for pci express Aleksandr Bezzubikov
2017-06-29 23:30   ` Michael S. Tsirkin
2017-06-29 21:56 ` [Qemu-devel] [PATCH RFC 6/6] hw/ich9: enable acpi pci hotplug Aleksandr Bezzubikov
2017-06-29 23:31   ` Michael S. Tsirkin
2017-06-29 23:17 ` [Qemu-devel] [PATCH RFC 0/6] q35: add acpi pci hotplug support Michael S. Tsirkin
2017-06-30  7:25   ` Marcel Apfelbaum
2017-06-30 19:19     ` Michael S. Tsirkin
2017-07-03 12:27     ` Igor Mammedov
2017-07-03 13:58       ` Alexander Bezzubikov
2017-07-03 14:41         ` Alexander Bezzubikov
2017-07-03 16:37           ` Michael S. Tsirkin
2017-07-03 16:34       ` Michael S. Tsirkin
2017-07-03 18:26         ` Marcel Apfelbaum
2017-07-03 18:29           ` Michael S. Tsirkin
2017-07-03 22:06             ` Alexander Bezzubikov
2017-07-04  1:00               ` Alexander Bezzubikov
2017-07-04 12:18                 ` Marcel Apfelbaum [this message]
2017-07-04 13:12         ` 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=6f9d9521-88c3-715d-e60f-d36d8314e5da@redhat.com \
    --to=marcel@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=zuban32s@gmail.com \
    /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).