RE: [External] openbmc Digest, Vol 44, Issue 120

RE: [External] openbmc Digest, Vol 44, Issue 120

[Sumeet Kochar]

I want to seek input from the community on QEMU support from BMC chip vendors for their new BMC chips. OpenBMC has gone a long way in driving a consistent BMC chip abstraction layer to make it easy for multiple BMC chips to be supported but there is still a lead time to gain confidence to port on a new chip. We all know next gen BMC chips will come out in coming years. Personally to us, if BMC chip vendors can support QEMU models to go with their BSP drops then it will be a big benefit to both chip vendors and integrators of code stack. It will promote early work for new chip, weed out obvious new driver quality issues hence lessen the concerns around switch and extend early reach of new chip development beyond what EVB like hardware vehicles can achieve. Credit to those who have done this QEMU work in past, even though they have had integration roles, but we could all benefit with knowledge chip vendors have to get more complete QEMU models while integrators focus on features higher up the stack. There is value in using the QEMU models, as we know, even after initial new chip support as part of continuous integration sniff test concepts this community has been promoting already. If early model access needs to be restricted to parties authorized to such information, that could be a discussion. 

-----Original Message-----
From: openbmc <openbmc-bounces+skochar=lenovo.com@lists.ozlabs.org> On Behalf Of openbmc-request@lists.ozlabs.org
Sent: Monday, April 29, 2019 10:00 PM
To: openbmc@lists.ozlabs.org
Subject: [External] openbmc Digest, Vol 44, Issue 120

Send openbmc mailing list submissions to
	openbmc@lists.ozlabs.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.ozlabs.org/listinfo/openbmc
or, via email, send a message with subject or body 'help' to
	openbmc-request@lists.ozlabs.org

You can reach the person managing the list at
	openbmc-owner@lists.ozlabs.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of openbmc digest..."


Today's Topics:

   1. A draft Redfish logging proposal (Brad Bishop)
   2. Re: ikvm refresh failed on host screen 1680x1050 resolution
      (=?ISO-8859-1?B?eGl1emhp?=)


----------------------------------------------------------------------

Message: 1
Date: Mon, 29 Apr 2019 21:01:55 -0400
From: Brad Bishop <bradleyb@fuzziesquirrel.com>
To: ed.tanous@intel.com
Cc: openbmc@lists.ozlabs.org, thalerj@us.ibm.com
Subject: A draft Redfish logging proposal
Message-ID: <20190430010155.4jnoyqkug3qohsb5@thinkpad>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Ed, OpenBMC community

Thanks for the great discussion about OEM in Redfish on OpenBMC on the community call today.

I decided to start a new thread rather than add on to Andrews
(https://lists.ozlabs.org/pipermail/openbmc/2019-April/015916.html) because that thread is at 10000ft and for this one I'd like to come down to 50ft.

Below you will find some mock-ups that have been floating around over here that show where we are headed in terms of logging support on our IBM systems.

The hope is we can keep the conversation from the community call today going but with something concrete (and written down) to talk over.  So please have a look and offer impressions, poke holes, etc.

The JSON below looks great in Mutt but just incase someones MUAs trashes the code formatting I've put these in a paste too: https://pastebin.com/fWnqWH77

The first object is a problem log entry, the second an audit log entry and the third a maintenance log entry.

Thanks!
-brad

{
    "@odata.context": "/redfish/v1/$metadata#LogEntry.LogEntry",
    "@odata.id":        "/redfish/v1/Managers/BMC/LogServices/Problems/Entries/1/",
    "@odata.type": "#LogEntry.v1_0_0.LogEntry",
    "Created": "2018-06-15T14:07:47Z",
    "EntryType": "Event",
    "Id": "1", // Log Position
    "Message": "Description of the problem",
    "MessageID": "SRC or LC CommonEventID",
    "MessageArgs": ["Arg1", "Arg2"...."ArgN"],
    "Name": "OpenBMC Event Log",
    "Links": {
        "OriginOfCondition": {
            //This is the URI of the resource that caused the log entry.
            //Think FRU List
            "@odata.id": "Link to inventory item."
        }
        "Oem": {
            "@odata.id": "LinkToPEL" //provides a link to the PEL location
        }
    },
    "Severity": "Critical, Warning, or Info",
    "Oem": 
    {
        "IBM": 
        {
            "@odata.context": "/redfish/v1/$metadata#IBMLogEntry.IBMLogEntry",
            "@odata.type": "#HpeLogEntry.v2_1_0.IBMLogEntry",
            "Serviceable": true or false,
            "Resolved": true or false,
            "UpdatedTime" : <timestamp>,
            "EventType": < 1 of IBM EventTypes>,
            "AffectedSubsystem": <Take from PEL or PolicyTable>,

            "CallHome": true or false,
            "Notified": [
                //Maybe use this instead?
                //https://www.dmtf.org/sites/default/files/Redfish%20School%20-%20Events.pdf
                //page 5
                <UUID>: true or false
            ], 
            "Version": 1.0
        }
    },
}

{
    "@odata.context": "/redfish/v1/$metadata#LogEntry.LogEntry",
    "@odata.id": "/redfish/v1/Managers/BMC/LogServices/Audit/Entries/1/",
    "@odata.type": "#LogEntry.v1_0_0.LogEntry",
    "Created": "2018-06-15T14:07:47Z",
    "EntryType": "Event",
    "Id": "1", //log position
    "Message": "Description of the problem", //ex. ?User <ID> ADMIN logged in from 192.168.1.5?,
    "MessageID": "SRC or LC Common Event ID",
    "MessageArgs": ["Arg1", "Arg2"...."ArgN"],
    "Name": "OpenBMC Audit Log",
    "Severity": "Warning, or Info",
    "Oem": 
    {
        "IBM": 
        {
            "EventNumber": "<logPosition>",
            "Serviceable": false,
            "Resolved": true, //Do we really need this?
            "UpdatedTime": "", //<timestamp>,
            "EventType": "", //< 1 of Administrative, Security>,
            "AffectedSubsystem": "Systems Management - Core / Virtual Appliance",
            "CallHome": false,
            "Notified": [
                "<UUID>": true or false
            ]
        }
    },
    "OemRecordFormat": "IBM-OpenLogging", }

{
    "@odata.context": "/redfish/v1/$metadata#LogEntry.LogEntry",
    "@odata.id": "/redfish/v1/Managers/BMC/LogServices/Maintenance/Entries/1/",
    "@odata.type": "#LogEntry.v1_0_0.LogEntry",
    "Created": "2018-06-15T14:07:47Z",
    "EntryType": "OEM",
    "Id": "1", //log position
    "Message": "Description of the problem", //ex CPU changed from SN: 12345 to SN: 12445
    "MessageID": "SRC or LC Common Event ID",
    "MessageArgs": ["Arg1", "Arg2"...."ArgN"],
    "Name": "OpenBMC Log",
    "Severity": "Info",
    "Links": {
        "OriginOfCondition": {
            //"This is the URI of the resource that caused the log entry. Think FRU List"
            "@odata.id": "Link to inventory item."
        }
        "Oem": {
            "@odata.id": "LinkToPEL" //provides a link to the PEL location
        }
    },
    "Oem": 
    {
        "IBM": 
        {
            "Serviceable": false,
            "Resolved": true,
            "UpdatedTime" : "<timestamp>",
            "EventType": "< 1 of EventTypes>",
            "AffectedSubsystem": "", //<Take from PEL or PolicyTable>
            "CallHome": false,
            "Notified": [
                "<UUID>": true or false
            ]
        }
    },
    "OemRecordFormat": "IBM-OpenLogging",
    "Version": 1.0
}


------------------------------

Message: 2
Date: Tue, 30 Apr 2019 09:30:43 +0800
From: "=?ISO-8859-1?B?eGl1emhp?=" <1450335857@qq.com>
To: "=?ISO-8859-1?B?amFlLmh5dW4ueW9v?="
	<jae.hyun.yoo@linux.intel.com>, "=?ISO-8859-1?B?b3BlbmJtYw==?="
	<openbmc@lists.ozlabs.org>, "=?ISO-8859-1?B?ZWQ=?=" <ed@tanous.net>,
	"=?ISO-8859-1?B?RWRkaWUgSmFtZXM=?=" <eajames@linux.vnet.ibm.com>
Subject: Re: ikvm refresh failed on host screen 1680x1050 resolution
Message-ID: <tencent_5FB0BF811DCC8BEA504F5A8F@qq.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi Jae,
    Did you reproduce the resolution issue? CentOS7 or RedHat7 has this resolution.
  Bets,
Xiuzhi
Hi Jae,
   My host OS is RedHat7. 
Both "Refresh" button on ikvm web Page and "View--Reload This Page" or reload button on chrome browser menu works.
Xiuzhi


------------------ Original ------------------
From:  "jae.hyun.yoo";<jae.hyun.yoo@linux.intel.com>;
Date:  Apr 5, 2019
To:  "xiuzhi"<1450335857@qq.com>; "openbmc"<openbmc@lists.ozlabs.org>; "ed"<ed@tanous.net>; "Eddie James"<eajames@linux.vnet.ibm.com>; 

Subject:  Re: ikvm refresh failed on host screen 1680x1050 resolution



On 4/3/2019 10:21 PM, xiuzhi wrote:
> Hi Jae, Ed,
>      The ikvm screen cann't refresh on ikvm webui screen when setting 
> the host screen resolution to 1680*1050 . I must click the "Refresh"
> button to get the new host screen.  Other resolutions works very well.
>    Please check it.

Hi Xiuzhi,

I can't see the resolution option in Ubuntu 18.03. What host OS did you use for the test? Let me clarify one more. Do you mean the "Refresh"
button in KVM web page, or reload button of the web browser?

Thanks,
Jae

> Best,
> xiuzhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20190430/b9d3f13a/attachment-0001.htm>

End of openbmc Digest, Vol 44, Issue 120
****************************************

Re: [External] openbmc Digest, Vol 44, Issue 120

[Andrew Jeffery]

Hi Sumeet,

On Wed, 1 May 2019, at 10:56, Sumeet Kochar wrote:
> I want to seek input from the community on QEMU support from BMC chip 
> vendors for their new BMC chips.

I agree it would be great to have the chip vendors on board. I think some have
seen the utility of qemu, but ultimately it's up to them to either act on it for
their own purposes or for their customers to start pressuring for this as part
of their purchase arrangement.

We can start advocating for it as a community, but given the community isn't
the one purchasing the chips we don't have a lot of sway. As such from a
community perspective it's largely still a scratch-your-own-itch problem.

As such if you want to see improved qemu support please don't hesitate to
start contributing! Just like the kernel, we want the patches upstream, so
send them there first and we can backport as required.

Cheers,

Andrew