All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 4/5] x86/PV: remove the emulated PIT
Date: Thu, 14 Jan 2016 15:03:04 +0100	[thread overview]
Message-ID: <5697AA98.5050305@citrix.com> (raw)
In-Reply-To: <5697A4BA02000078000C6B78@prv-mh.provo.novell.com>

El 14/01/16 a les 13.38, Jan Beulich ha escrit:
>>>> On 14.01.16 at 11:59, <roger.pau@citrix.com> wrote:
>> El 14/01/16 a les 10.11, Jan Beulich ha escrit:
>>>>>> On 14.01.16 at 09:25, <roger.pau@citrix.com> wrote:
>>>> El 13/01/16 a les 17.36, Jan Beulich ha escrit:
>>>>>>>> On 13.01.16 at 13:32, <roger.pau@citrix.com> wrote:
>>>>>> The HVMlite series removed the initialization of the emulated PIT for PV
>>>>>> guests, but the handler was still reachable, which means a PV guests can
>>>>>> crash Xen if it pokes at IO ports 0x42, 0x43 or 0x61. Completely remove the
>>>>>> PV PIT handler and move the PIT initialization to HVM guests only.
>>>>>
>>>>> As said on IRC - this is needed for Dom0 to be able to drive the
>>>>> PC speaker. You'll need to provide a fix for the suppressed
>>>>> initialization instead, at least for Dom0. (As an aside, your patch
>>>>> orphans hwdom_pit_access().)
>>>>
>>>> Thanks for the clarification. AFAICT I can leave the usage of
>>>> hwdom_pit_access for Dom0, and completely remove PIT access for DomU, is
>>>> that right?
>>>
>>> I don't think so - see the explanation Tim gave on IRC. Afaict the
>>> mention of BIOS here isn't related to a virtual BIOS, but to that
>>> of a passed through graphics card.
>>
>> I'm sorry but I still don't fully understand why that's needed, and it
>> arises a couple of questions. First of all, the only reference that I
>> can find about BIOS and i8254 usage is regarding VGA BIOS POST [0],
>> where they mention that the VGA POST method might make use of the i8254.
>>
>> This seems reasonable, but I still don't understand why we provide an
>> emulated i8254 to DomUs. They don't have access to the low 1MB, which is
>> where the VGA BIOS resides, so there's no way they can call into the VGA
>> POST at all.
> 
> All of this arrangement predates me, but see the original change
> introducing this: "Provide PV guests with emulated PIT", which
> suggests this wasn't just for Dom0. I'm hesitant to accept removal
> of code when we don't know exactly by whom and for what purpose
> it might be used. When I enabled Dom0 speaker control, I
> intentionally retained the original code for DomU purposes.

What about we do the following: enable the PIT for PV(H) guests
(DomU/Dom0), and completely remove it for HVMlite guests for the moment?

We might consider enabling it for HVMlite, but the plan is that this
could be done on a per-domain basis using the flags in the
xen_arch_domainconfig struct.

Roger.

  reply	other threads:[~2016-01-14 14:03 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-13 12:32 [PATCH 0/5] HVMlite: minor fixes and Dom0 preparatory patches Roger Pau Monne
2016-01-13 12:32 ` [PATCH 1/5] xen/elfnotes: initialise phys_entry to UNSET_ADDR32 Roger Pau Monne
2016-01-13 12:46   ` Jan Beulich
2016-01-13 12:52     ` Roger Pau Monné
2016-01-13 13:02       ` Jan Beulich
2016-01-13 13:05         ` Andrew Cooper
2016-01-13 13:08           ` Jan Beulich
2016-01-13 13:10             ` Andrew Cooper
2016-01-13 12:32 ` [PATCH 2/5] libelf: rewrite symtab/strtab loading for Dom0 Roger Pau Monne
2016-01-13 12:32 ` [PATCH 3/5] x86/hvm: don't set the BSP as initialised in hvm_vcpu_initialise Roger Pau Monne
2016-01-13 16:29   ` Jan Beulich
2016-01-13 17:23     ` Roger Pau Monné
2016-01-14  9:07       ` Jan Beulich
2016-01-13 12:32 ` [PATCH 4/5] x86/PV: remove the emulated PIT Roger Pau Monne
2016-01-13 16:36   ` Jan Beulich
2016-01-14  8:25     ` Roger Pau Monné
2016-01-14  9:11       ` Jan Beulich
2016-01-14 10:59         ` Roger Pau Monné
2016-01-14 12:38           ` Jan Beulich
2016-01-14 14:03             ` Roger Pau Monné [this message]
2016-01-14 14:36               ` Jan Beulich
2016-01-13 12:32 ` [PATCH 5/5] x86/HVM: don't setup an intercept handler for IO port 0xcf8 unconditionally Roger Pau Monne
2016-01-13 16:38   ` Jan Beulich
2016-01-13 16:45     ` Andrew Cooper
2016-01-13 16:48     ` Paul Durrant
2016-01-14  8:35       ` Roger Pau Monné
2016-01-14  9:12         ` Jan Beulich
2016-01-14 10:50           ` Andrew Cooper
2016-01-14 11:00             ` Roger Pau Monné

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=5697AA98.5050305@citrix.com \
    --to=roger.pau@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.