From: Chuck Zmudzinski <brchuckz@aol.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-devel@nongnu.org,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>,
"Daniel P. Berrange" <berrange@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Michael Roth <michael.roth@amd.com>,
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Subject: Re: [PATCH] pci: add enforce_slot_reserved_mask_manual property
Date: Sat, 28 Jan 2023 16:46:16 -0500 [thread overview]
Message-ID: <11f61b6b-df71-d3f2-d01d-1b4101b9126f@aol.com> (raw)
In-Reply-To: <20230128141348-mutt-send-email-mst@kernel.org>
On 1/28/23 2:14 PM, Michael S. Tsirkin wrote:
> On Sat, Jan 28, 2023 at 08:20:55AM -0500, Chuck Zmudzinski wrote:
>> On 1/28/23 5:26 AM, Michael S. Tsirkin wrote:
>> > On Fri, Jan 27, 2023 at 10:39:28PM -0500, Chuck Zmudzinski wrote:
>> >> On 1/27/2023 8:28 AM, Michael S. Tsirkin wrote:
>> >> > On Sun, Jan 15, 2023 at 07:49:51PM -0500, Chuck Zmudzinski wrote:
>> >> > > The current reserved slot check in do_pci_register_device(), added with
>> >> > > commit 8b8849844fd6
>> >> >
>> >> > add ("subject here") please
>> >> >
>> >> > > ,is done even if the pci device being added is
>> >> > > configured manually for a particular slot. The new property, when set
>> >> > > to false, disables the check when the device is configured to request a
>> >> > > particular slot. This allows an administrator or management tool to
>> >> > > override slot_reserved_mask for a pci device by requesting a particular
>> >> > > slot for the device. The new property is initialized to true which
>> >> > > preserves the existing behavior of slot_reserved_mask by default.
>> >> > >
>> >> > > Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
>> >> >
>> >> > Thanks!
>> >> > I'm trying to think of the best default for this.
>> >>
>> >> I think it would be better for the default value of
>> >> enforce_slot_reserved_mask_manual to be false, so that a
>> >> user-specified slot will by default override slot_reserved_mask.
>> >> But doing that would change the current behavior of
>> >> slot_reserved_mask.
>> >>
>> >> Currently, this is the only place where slot_reserved_mask is used in all
>> >> of the Qemu source (code from hw/sparc64/sun4u.c):
>> >>
>> >> ------ snip -------
>> >> /* Only in-built Simba APBs can exist on the root bus, slot 0 on busA is
>> >> reserved (leaving no slots free after on-board devices) however slots
>> >> 0-3 are free on busB */
>> >> pci_bus->slot_reserved_mask = 0xfffffffc;
>> >> pci_busA->slot_reserved_mask = 0xfffffff1;
>> >> pci_busB->slot_reserved_mask = 0xfffffff0;
>> >> ------ snip -------
>> >>
>> >> I think we could safely change the default value of
>> >> enforce_slot_reserved_mask_manual to false but set
>> >> it to true for the sparc64 sun4u board here to preserve
>> >> the current behavior of the only existing board in Qemu
>> >> that uses slot_reserved_mask.
>> >>
>> >> What do you think?
>> >
>> > I guess first can you answer whether this is still needed
>> > with the latest Xen patches?
>> >
>>
>> It's not really needed except for experimental purposes to allow
>> an administrator to test experimental configurations with a device
>> other than the igd at slot 2. That might be useful in some cases,
>> but it is not really necessary unless someone asks for that capability.
>> If libvirt users who ordinarily like to manually specify all the
>> settings will be OK with the proposed patch to xen that prevents
>> an administrator from being able to override a new setting that
>> reserves slot 2 for the igd for type "xenfv" machines configured for
>> igd passthrough, then there is no need for this patch. I don't think
>> many users need the capability to insert a different device in slot 2 for
>> the "xenfv" machine type configured with igd-passthru=on, so I would be
>> OK if this patch is not included in qemu.
>>
>> Chuck
>
> Pls wait and see if that patch gets picked up. Let me know.
>
A day or two ago Anthony said he would look at the xen patch soon. So we'll
just wait for him, and I'll let you know if he is going to pull it up.
next prev parent reply other threads:[~2023-01-28 21:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ad5f5cf8bc4bd4a720724ed41e47565a7f27adf5.1673829387.git.brchuckz.ref@aol.com>
2023-01-16 0:49 ` [PATCH] pci: add enforce_slot_reserved_mask_manual property Chuck Zmudzinski
2023-01-27 13:28 ` Michael S. Tsirkin
2023-01-28 3:39 ` Chuck Zmudzinski
2023-01-28 10:26 ` Michael S. Tsirkin
2023-01-28 13:20 ` Chuck Zmudzinski
2023-01-28 19:14 ` Michael S. Tsirkin
2023-01-28 21:46 ` Chuck Zmudzinski [this message]
2023-01-30 16:36 ` Chuck Zmudzinski
2023-01-28 21:58 ` Mark Cave-Ayland
2023-01-29 3:00 ` Chuck Zmudzinski
2023-03-06 16:37 ` Chuck Zmudzinski
2023-03-12 14:13 ` Mark Cave-Ayland
2023-03-12 19:58 ` Chuck Zmudzinski
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=11f61b6b-df71-d3f2-d01d-1b4101b9126f@aol.com \
--to=brchuckz@aol.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=michael.roth@amd.com \
--cc=mst@redhat.com \
--cc=pbonzini@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).