public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Wang, Jian J" <jian.j.wang@intel.com>
To: "lersek@redhat.com" <lersek@redhat.com>,
	"Justen, Jordan L" <jordan.l.justen@intel.com>,
	"Yao, Jiewen" <jiewen.yao@intel.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	"Kinney, Michael D" <michael.d.kinney@intel.com>
Subject: ASSERT in QemuVideoDxe driver during reset
Date: Wed, 6 Sep 2017 08:15:43 +0000	[thread overview]
Message-ID: <D827630B58408649ACB04F44C510003624C820A4@SHSMSX103.ccr.corp.intel.com> (raw)

Hi guys,

I found an ASSERT issue in function InstallVbeShim() in QemuVideoDxe driver during reset. The assert statement is like below.

    ASSERT (Int0x10->Segment == 0x0000);
    ASSERT (Int0x10->Offset  == 0x0000);

This happened after I have enabled NULL pointer access detection feature, in which page 0 (4K)  is disabled. And because of page 0 disabled, I have to skip the memory clearing for page 0 in DXE core. Otherwise it will cause page fault exception there. It seems that QEMU may clear all its memory at startup. Skipping the action of clearing page 0 in core won't cause ASSERT issue in QemuVideoDxe, for the first time boot. But QemuVideoDxe will write int10 vector at memory 0x10 and QEMU will not clear all its memory during warm boot. ASSERT will be triggered after reset.

It's easy to fix this issue but there're some subtle situations which I'm not quite certain. I'd like your opinions for them.

Here're my thoughts on several solutions:
a) Remove the ASSERT statement in InstallVbeShim(). But I'm sure if it is safe to do so because I don't quite understand the purpose of the ASSERT. 
b) Instead of skipping clearing page 0, enable it, do clearing and then disable it. The problem here is that CPU arch protocol is not ready at that time. I have to "manually" do page operation, which might be non-portable and a little bit odd in DXE core.
c) Move code clearing page 0 from DXE core to another place wherever appropriate, like DxeIpl or cpu driver. But I think there's a good reason to put code there before.

Thanks,
Wang, Jian J


             reply	other threads:[~2017-09-06  8:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-06  8:15 Wang, Jian J [this message]
2017-09-06 10:20 ` ASSERT in QemuVideoDxe driver during reset Laszlo Ersek
2017-09-06 11:16   ` Yao, Jiewen
2017-09-06 13:18     ` Laszlo Ersek
2017-09-06 14:47       ` Gao, Liming
2017-09-06 15:35         ` Laszlo Ersek
2017-09-06 15:06       ` Yao, Jiewen
2017-09-06 15:25         ` Laszlo Ersek
2017-09-07  0:54           ` Yao, Jiewen
2017-09-07  0:41     ` Wang, Jian J
2017-09-07  1:28       ` Yao, Jiewen
2017-09-07 10:58         ` Laszlo Ersek
2017-09-07 11:16           ` Yao, Jiewen

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-list 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=D827630B58408649ACB04F44C510003624C820A4@SHSMSX103.ccr.corp.intel.com \
    --to=devel@edk2.groups.io \
    /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