hw/ipmi/ipmi_bmc_sim.c | 22 ++++++++++++++-------- include/hw/qdev-properties.h | 7 +++++++ qemu-options.hx | 10 +++++++--- 3 files changed, 28 insertions(+), 11 deletions(-)
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(-)
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
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
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
© 2016 - 2024 Red Hat, Inc.