qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Klaus Jensen <its@irrelevant.dk>
To: Major Saheb <majosaheb@gmail.com>
Cc: Peter Xu <peterx@redhat.com>,
	k.jensen@samsung.com, philmd@linaro.org, armbru@redhat.com,
	mst@redhat.com, lukasz.gieryk@linux.intel.com,
	Alex Williamson <alex.williamson@redhat.com>,
	Bjorn Helgaas <helgaas@kernel.org>,
	Alberto Faria <afaria@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: DMAR fault with qemu 7.2 and Ubuntu 22.04 base image
Date: Tue, 14 Feb 2023 15:56:47 +0100	[thread overview]
Message-ID: <Y+uhL77aBFVEWsJd@cormorant.local> (raw)
In-Reply-To: <Y+uHMm1hvP7N6sKD@cormorant.local>

[-- Attachment #1: Type: text/plain, Size: 2109 bytes --]

On Feb 14 14:05, Klaus Jensen wrote:
> On Feb 14 17:34, Major Saheb wrote:
> > Thanks Peter for the reply. I tried to connect gdb to qemu and able to
> > break 'vtd_iova_to_slpte()', I dumped the following with both Ubuntu
> > 20.04 base image container which is the success case and Ubuntu 22.04
> > base image container which is failure case
> > One thing I observed is the NvmeSQueue::dma_addr is correctly set to
> > '0x800000000', however in failure case this value is 0x1196b1000. A
> > closer look indicates more fields in NvmeSQueue might be corrupted,
> > for example we are setting admin queue size as 512 but in failure case
> > it is showing 32.
> > 
> 
> Hi Major,
> 
> It's obviously pretty bad if hw/nvme somehow corrupts the SQ structure,
> but it's difficult to say from this output.
> 
> Are you configuring shadow doorbells (the db_addr and ei_addr's are
> set in both cases)?
> 
> > > > Following is the partial qemu command line that I am using
> > > >
> > > > -device intel-iommu,intremap=on,caching-mode=on,eim=on,device-iotlb=on,aw-bits=48
> > > >
> 
> I'm not sure if caching-mode=on and device-iotlb=on leads to any issues
> here? As far as I understand, this is mostly used with stuff like vhost.
> I've tested and developed vfio-based drivers against hw/nvme excessively
> and I'm not using anything besides `-device intel-iommu`.
> 
> Do I undestand correctly that your setup is "just" a Ubuntu 22.04 guest
> with a container and a user-space driver to interact with the nvme
> devices available on the guest? No nested virtualization with vfio
> passthrough?

Assuming you are *not* explicitly configuring shadow doorbells, then I
think you might have a broken driver that does not properly reset the
controller before using it (are you tripping CC.EN?). That could explain
the admin queue size of 32 (default admin queue depth for the Linux nvme
driver) as well as the db/ei_addrs being left over. And behavior wrt.
how the Linux driver disables the device might have changed between the
kernel version used in Ubuntu 20.04 and 22.04.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2023-02-14 14:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-13 16:45 DMAR fault with qemu 7.2 and Ubuntu 22.04 base image Major Saheb
2023-02-13 22:21 ` Peter Xu
2023-02-14 12:04   ` Major Saheb
2023-02-14 13:05     ` Klaus Jensen
2023-02-14 14:56       ` Klaus Jensen [this message]
2023-02-15  6:31         ` Major Saheb
2023-02-15  7:35           ` Klaus Jensen

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=Y+uhL77aBFVEWsJd@cormorant.local \
    --to=its@irrelevant.dk \
    --cc=afaria@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=armbru@redhat.com \
    --cc=helgaas@kernel.org \
    --cc=k.jensen@samsung.com \
    --cc=lukasz.gieryk@linux.intel.com \
    --cc=majosaheb@gmail.com \
    --cc=mst@redhat.com \
    --cc=peterx@redhat.com \
    --cc=philmd@linaro.org \
    --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).