mbox

[PULL,0/2] Add a UUID device property to IPMI

Message ID 20190627124815.29536-1-minyard@acm.org (mailing list archive)
State New, archived
Headers show

Pull-request

git://github.com/cminyard/qemu.git tags/ipmi-for-release-20190627

Message

Corey Minyard June 27, 2019, 12:48 p.m. UTC
I believe we are not in softfreeze yet, and this is the only real
fix I have for IPMI at the moment.

This was posted Nov 2018 with little commentary.

The following changes since commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde:

  Merge remote-tracking branch 'remotes/amarkovic/tags/mips-queue-jun-21-2019' into staging (2019-06-21 15:40:50 +0100)

are available in the Git repository at:

  git://github.com/cminyard/qemu.git tags/ipmi-for-release-20190627

for you to fetch changes up to bddef5881d0c935a5d9d8e15f822d9d700666ae6:

  ipmi: Add a UUID device property (2019-06-26 15:31:33 -0500)

----------------------------------------------------------------
Add a UUID device property to IPMI

This is fairly important for two reasons:

* It allows a BMC to be created with no UUID, returning an error, which
  is the behavior of many BMCs in the world.
* It lets the user set the UUID to a fixed value.

Some software using IPMI will get confused if it gets different UUIDs
from what should be the same device, which is what happens now if qemu
quits and restarts.

----------------------------------------------------------------
Corey Minyard (2):
      qdev: Add a no default uuid property
      ipmi: Add a UUID device property

 hw/ipmi/ipmi_bmc_sim.c       | 22 ++++++++++++++--------
 include/hw/qdev-properties.h |  7 +++++++
 qemu-options.hx              | 10 +++++++---
 3 files changed, 28 insertions(+), 11 deletions(-)

Comments

Peter Maydell July 1, 2019, 6:10 p.m. UTC | #1
On Thu, 27 Jun 2019 at 13:48, <minyard@acm.org> wrote:
>
> I believe we are not in softfreeze yet, and this is the only real
> fix I have for IPMI at the moment.
>
> This was posted Nov 2018 with little commentary.
>
> The following changes since commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde:
>
>   Merge remote-tracking branch 'remotes/amarkovic/tags/mips-queue-jun-21-2019' into staging (2019-06-21 15:40:50 +0100)
>
> are available in the Git repository at:
>
>   git://github.com/cminyard/qemu.git tags/ipmi-for-release-20190627
>
> for you to fetch changes up to bddef5881d0c935a5d9d8e15f822d9d700666ae6:
>
>   ipmi: Add a UUID device property (2019-06-26 15:31:33 -0500)
>
> ----------------------------------------------------------------
> Add a UUID device property to IPMI
>
> This is fairly important for two reasons:
>
> * It allows a BMC to be created with no UUID, returning an error, which
>   is the behavior of many BMCs in the world.
> * It lets the user set the UUID to a fixed value.
>
> Some software using IPMI will get confused if it gets different UUIDs
> from what should be the same device, which is what happens now if qemu
> quits and restarts.
>
> ----------------------------------------------------------------
> Corey Minyard (2):
>       qdev: Add a no default uuid property
>       ipmi: Add a UUID device property

I have to say I'm not entirely happy with applying a pullreq
with patches that are unreviewed and were last posted on list
over six months ago. Can you post a v2 to try to solicit code
review for them before we put them into master, please?

(Sometimes patches don't get review, and we generally take
them anyway; I do that myself from time to time. It's the
combination of the six-months-since-patches-posted plus the
imminent freeze deadline that gives me pause in this case.)

thanks
-- PMM
Corey Minyard July 1, 2019, 6:25 p.m. UTC | #2
On Mon, Jul 01, 2019 at 07:10:50PM +0100, Peter Maydell wrote:
> On Thu, 27 Jun 2019 at 13:48, <minyard@acm.org> wrote:
> >
> > I believe we are not in softfreeze yet, and this is the only real
> > fix I have for IPMI at the moment.
> >
> > This was posted Nov 2018 with little commentary.
> >
> > The following changes since commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde:
> >
> >   Merge remote-tracking branch 'remotes/amarkovic/tags/mips-queue-jun-21-2019' into staging (2019-06-21 15:40:50 +0100)
> >
> > are available in the Git repository at:
> >
> >   git://github.com/cminyard/qemu.git tags/ipmi-for-release-20190627
> >
> > for you to fetch changes up to bddef5881d0c935a5d9d8e15f822d9d700666ae6:
> >
> >   ipmi: Add a UUID device property (2019-06-26 15:31:33 -0500)
> >
> > ----------------------------------------------------------------
> > Add a UUID device property to IPMI
> >
> > This is fairly important for two reasons:
> >
> > * It allows a BMC to be created with no UUID, returning an error, which
> >   is the behavior of many BMCs in the world.
> > * It lets the user set the UUID to a fixed value.
> >
> > Some software using IPMI will get confused if it gets different UUIDs
> > from what should be the same device, which is what happens now if qemu
> > quits and restarts.
> >
> > ----------------------------------------------------------------
> > Corey Minyard (2):
> >       qdev: Add a no default uuid property
> >       ipmi: Add a UUID device property
> 
> I have to say I'm not entirely happy with applying a pullreq
> with patches that are unreviewed and were last posted on list
> over six months ago. Can you post a v2 to try to solicit code
> review for them before we put them into master, please?
> 
> (Sometimes patches don't get review, and we generally take
> them anyway; I do that myself from time to time. It's the
> combination of the six-months-since-patches-posted plus the
> imminent freeze deadline that gives me pause in this case.)

Will do.

I looked around and tried to find the freeze dates, and I couldn't
find anything published.  If I had known it was close, I would have
waited.

-corey
Peter Maydell July 1, 2019, 7:50 p.m. UTC | #3
On Mon, 1 Jul 2019 at 19:25, Corey Minyard <minyard@acm.org> wrote:
>
> On Mon, Jul 01, 2019 at 07:10:50PM +0100, Peter Maydell wrote:
> > I have to say I'm not entirely happy with applying a pullreq
> > with patches that are unreviewed and were last posted on list
> > over six months ago. Can you post a v2 to try to solicit code
> > review for them before we put them into master, please?
> >
> > (Sometimes patches don't get review, and we generally take
> > them anyway; I do that myself from time to time. It's the
> > combination of the six-months-since-patches-posted plus the
> > imminent freeze deadline that gives me pause in this case.)
>
> Will do.
>
> I looked around and tried to find the freeze dates, and I couldn't
> find anything published.  If I had known it was close, I would have
> waited.

Thanks. (Our schedule is on the wiki at
https://wiki.qemu.org/Planning/4.1 -- but we don't publicise
that url very much so it's easy to overlook it.)

This is a pretty small change so if it gets review we can
probably fit it in before rc0 or rc1.

-- PMM