qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Li Qiang <liq3ea@163.com>
Cc: Alex Williamson <alex.l.williamson@gmail.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Questions about 'emulated_config_bits' in vfio pci
Date: Fri, 30 Aug 2019 20:23:40 -0600	[thread overview]
Message-ID: <20190830202340.3815dde8@x1.home> (raw)
In-Reply-To: <5D69CE0F.011DCE.26140@m12-11.163.com>

On Sat, 31 Aug 2019 09:31:59 +0800
Li Qiang <liq3ea@163.com> wrote:

> Hi Alex and all,
> 
> My understanding for ‘emulated_config_bits’ in ‘VFIOPCIDevice’ is
> that this is the mask for PCI config space. If the bits is set in ‘
> emulated_config_bits’ then we can just use the qemu’s
> ‘vdev->pdev.config’, it the bits is not set, we need to ask the
> physical device. 

Yes.

> But there are two places I got confused in ‘vfio_realize’.
> 
> Here in ‘vfio_realize’
>     /* QEMU can change multi-function devices to single function, or
> reverse */ vdev->emulated_config_bits[PCI_HEADER_TYPE] =
>                                               PCI_HEADER_TYPE_MULTI_FUNCTION;
> 
> In ‘vfio_add_std_cap’
> 
>         /* Begin the rebuild, use QEMU emulated list bits */
>         pdev->config[PCI_CAPABILITY_LIST] = 0;
>         vdev->emulated_config_bits[PCI_CAPABILITY_LIST] = 0xff;
>         vdev->emulated_config_bits[PCI_STATUS] |= PCI_STATUS_CAP_LIST;
> 
> 
> Per my understanding, I think ‘emulated_config_bits’ should be set to
> 0xff just as other places. But here use
> ‘PCI_HEADER_TYPE_MULTI_FUNCTION’ and ‘PCI_STATUS_CAP_LIST’. In fact,
> this doesn’t affect the results, but it’s confusion. Just a typo? Or
> other reasons.

I'm not sure I understand the question.  We're only trying to emulate
the multi-function bit of the header-type register and the capability
list bit of the status register, therefore we set only these bits in
the emulated bits mask.  The header type is static, so it doesn't make
much difference if we emulate the entire 8-bit register or only this
bit (I don't think it's worth the optimization and doing so potentially
masks what we're trying to accomplish).  The status register though is
partially static and partially dynamic, some bits are reporting the
current device status.  So I don't see that we'd ever want to emulate
all of the bits in that register.  emulate_config_bits has bit level
granularity to which bits of config space are emulated in QEMU, so
we're not always going to set a full byte for emulation.  Thanks,

Alex


  reply	other threads:[~2019-08-31  2:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-31  1:31 [Qemu-devel] Questions about 'emulated_config_bits' in vfio pci Li Qiang
2019-08-31  2:23 ` Alex Williamson [this message]
2019-08-31  2:44   ` [Qemu-devel] 答复: " Li Qiang

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=20190830202340.3815dde8@x1.home \
    --to=alex.williamson@redhat.com \
    --cc=alex.l.williamson@gmail.com \
    --cc=liq3ea@163.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).