From: Thomas Huth <thuth@redhat.com>
To: Yi Min Zhao <zyimin@linux.ibm.com>, qemu-devel@nongnu.org
Cc: qemu-s390x@nongnu.org, Cornelia Huck <cohuck@redhat.com>
Subject: Re: [Qemu-devel] [qemu-s390x] [PATCH] s390x/pci: add common fmb
Date: Mon, 1 Oct 2018 11:22:24 +0200 [thread overview]
Message-ID: <2b7b5736-f461-4c07-1af8-a46796f22564@redhat.com> (raw)
In-Reply-To: <809560dd-3fff-3cec-5b65-cb7e5cd32383@linux.ibm.com>
On 2018-09-29 07:48, Yi Min Zhao wrote:
>
> 在 2018/9/19 下午3:53, Thomas Huth 写道:
>> On 2018-09-19 09:08, Yi Min Zhao wrote:
[...]
>>>> diff --git a/hw/s390x/s390-pci-bus.h b/hw/s390x/s390-pci-bus.h
>>>> index 1f7f9b5814..fdf13a19c0 100644
>>>> --- a/hw/s390x/s390-pci-bus.h
>>>> +++ b/hw/s390x/s390-pci-bus.h
>>>> @@ -286,6 +286,28 @@ typedef struct S390PCIIOMMUTable {
>>>> S390PCIIOMMU *iommu[PCI_SLOT_MAX];
>>>> } S390PCIIOMMUTable;
>>>> +/* Function Measurement Block */
>>>> +#define DEFAULT_MUI 4000
>>>> +#define UPDATE_U_BIT 0x1ULL
>>>> +#define FMBK_MASK 0xfULL
>>>> +
>>>> +typedef struct ZpciFmbFmt0 {
>>>> + uint64_t dma_rbytes;
>>>> + uint64_t dma_wbytes;
>>>> +} ZpciFmbFmt0;
>>>> +
>>>> +typedef struct ZpciFmb {
>>>> + uint8_t format;
>>>> + uint8_t fmt_ind[3];
>>>> + uint32_t sample;
>>>> + uint64_t last_update;
>>>> + uint64_t ld_ops;
>>>> + uint64_t st_ops;
>>>> + uint64_t stb_ops;
>>>> + uint64_t rpcit_ops;
>>>> + ZpciFmbFmt0 fmt0;
>>>> +} QEMU_PACKED __attribute((__aligned__(8))) ZpciFmb;
>> All the fields in this struct are naturally aligned already, so I'd
>> maybe rather drop the QEMU_PACKED and add a
>> QEMU_BUILD_BUG_MSG(sizeof(ZpciFmb) != xx, ...) statement afterwards.
> Currently we only implement FMT0. There're other FMTs to be implemented
> in future.
> So here there would be a union and we can't give a specific size to
> QEMU_BUILD_BUG_MSG.
> Can we use the max size for checking?
I think you could use this to check the beginning of the struct:
QEMU_BUILD_BUG_MSG(offsetof(ZpciFmb, fmt0) != 48, "padding in ZpciFmb");
>>>> struct S390PCIBusDevice {
>>>> DeviceState qdev;
>>>> PCIDevice *pdev;
>>>> @@ -297,6 +319,8 @@ struct S390PCIBusDevice {
>>>> uint32_t fid;
>>>> bool fid_defined;
>>>> uint64_t fmb_addr;
>>>> + ZpciFmb fmb;
>> ... since you embed it here in another struct which does not have any
>> alignment requirements. This is likely going to cause an error with GCC
>> 8.1, we've had this problem in the past already:
>>
>> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=a6e4385dea94850d7b06b0
> Ah...I didn't test the code with gcc 8+. GCC I used is 7.2.
> It should get the same warining.
Nobody reported the warning in the s390-ccw bios until GCC 8 had been
released, so I assume this is a new warning in GCC 8.
>> Is the __align__(8) required at all? As far as I understand the code,
>> the struct is not living inside the guest memory, is it? So you could
>> simply drop the __align__(8).
>> But if you need it, I think you have to allocate the memory for ZpciFmb
>> separately (and use a "ZpciFmb *fmb" here instead).
> I want to copy the entire structure to the guest memory during updating
> FMB.
> It's not a good idea to do copy for all members multiple times.
Sure, but you're doing the updates through address_space_write(), so as
far as I can see there is currently no need for the
attribute((__aligned__(8))) here (or did I miss something?). Thus I'd
like to suggest to simply remove that attribute here.
Thomas
next prev parent reply other threads:[~2018-10-01 9:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-04 9:15 [Qemu-devel] [PATCH] s390x/pci: add common fmb Yi Min Zhao
[not found] ` <d1694693-0bfc-a8b3-c1b2-afc1c9954eac@linux.ibm.com>
[not found] ` <9f3259d4-5403-18b8-5588-1c51fd1f3da1@redhat.com>
[not found] ` <809560dd-3fff-3cec-5b65-cb7e5cd32383@linux.ibm.com>
2018-10-01 9:22 ` Thomas Huth [this message]
2018-10-16 7:19 ` [Qemu-devel] [qemu-s390x] " Yi Min Zhao
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=2b7b5736-f461-4c07-1af8-a46796f22564@redhat.com \
--to=thuth@redhat.com \
--cc=cohuck@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=zyimin@linux.ibm.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).