qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: pedro.principeza@canonical.com, ehabkost@redhat.com,
	dann.frazier@canonical.com,
	"Guilherme G. Piccoli" <gpiccoli@canonical.com>,
	qemu-devel@nongnu.org, christian.ehrhardt@canonical.com,
	lersek@redhat.com, fw@gpiccoli.net
Subject: Re: ovmf / PCI passthrough impaired due to very limiting PCI64 aperture
Date: Tue, 16 Jun 2020 18:16:06 +0100	[thread overview]
Message-ID: <20200616171606.GI2788@work-vm> (raw)
In-Reply-To: <20200616171026.jhlhtewp6j6vj44m@sirius.home.kraxel.org>

* Gerd Hoffmann (kraxel@redhat.com) wrote:
>   Hi,
> 
> > > If we can somehow make a *trustable* physbits value available to the
> > > guest, then yes, we can go that route.  But the guest physbits we have
> > > today unfortunately don't cut it.
> > 
> > In downstream RH qemu, we run with host-physbits as default; so it's reasonably
> > trustworthy;
> 
> Can the guest figure somehow whenever it is trustworthy or not?

At any one point in time there may be things that it can try and see how
the CPU responds but I'm not 100% sure.
I know there are some bodges in to make some MSR values 1 padded by the
right amount when crossing sizes that generally work.
(were those PAM registers or something - vague memories of an old
bug)

> > of course that doesn't help you across a migration between
> > hosts with different sizes (e.g. an E5 Xeon to an E3).
> 
> Making physbits configurable for migration compatibility is fine if qemu
> outlaws the problematic guest physbits > host physbits case and throws
> an error in that case.

I'm not sure that guest < host is entirely safe either though; although
it seems to work.

Dave

> take care,
>   Gerd
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK



  reply	other threads:[~2020-06-16 17:20 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-16 15:16 ovmf / PCI passthrough impaired due to very limiting PCI64 aperture Guilherme G. Piccoli
2020-06-16 16:50 ` Gerd Hoffmann
2020-06-16 16:57   ` Dr. David Alan Gilbert
2020-06-16 17:10     ` Eduardo Habkost
2020-06-17  8:17       ` Christophe de Dinechin
2020-06-17 16:25         ` Eduardo Habkost
2020-06-17  8:50       ` Daniel P. Berrangé
2020-06-17 10:28         ` Dr. David Alan Gilbert
2020-06-17 14:11         ` Eduardo Habkost
2020-06-16 17:10     ` Gerd Hoffmann
2020-06-16 17:16       ` Dr. David Alan Gilbert [this message]
2020-06-16 17:14     ` Guilherme Piccoli
2020-06-17  6:40       ` Gerd Hoffmann
2020-06-17 13:25         ` Laszlo Ersek
2020-06-17 13:26         ` Laszlo Ersek
2020-06-17 13:22       ` Laszlo Ersek
2020-06-17 13:43         ` Guilherme Piccoli
2020-06-17 15:57           ` Laszlo Ersek
2020-06-17 16:01             ` Guilherme Piccoli
2020-06-18  7:56               ` Laszlo Ersek
2020-06-17 13:46         ` Dr. David Alan Gilbert
2020-06-17 15:49           ` Eduardo Habkost
2020-06-17 15:57             ` Guilherme Piccoli
2020-06-17 16:33               ` Eduardo Habkost
2020-06-17 16:40                 ` Guilherme Piccoli
2020-06-18  8:00                 ` Laszlo Ersek
2020-06-17 16:04             ` Dr. David Alan Gilbert
2020-06-17 16:17               ` Daniel P. Berrangé
2020-06-17 16:22                 ` Eduardo Habkost
2020-06-17 16:41                   ` Dr. David Alan Gilbert
2020-06-17 17:17                     ` Daniel P. Berrangé
2020-06-17 17:23                       ` Dr. David Alan Gilbert
2020-06-17 16:28               ` Eduardo Habkost
2020-06-19 16:13               ` Dr. David Alan Gilbert
2020-06-17 16:14           ` Laszlo Ersek
2020-06-17 16:43             ` Laszlo Ersek
2020-06-17 17:02               ` Eduardo Habkost
2020-06-18  8:29                 ` Laszlo Ersek
2020-06-17  8:16   ` Christophe de Dinechin
2020-06-17 10:12     ` Gerd Hoffmann

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=20200616171606.GI2788@work-vm \
    --to=dgilbert@redhat.com \
    --cc=christian.ehrhardt@canonical.com \
    --cc=dann.frazier@canonical.com \
    --cc=ehabkost@redhat.com \
    --cc=fw@gpiccoli.net \
    --cc=gpiccoli@canonical.com \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=pedro.principeza@canonical.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).