[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 02/16] x86/traps: Clean up printing in do_reserved_trap()/fatal_trap()


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Mon, 11 May 2020 16:01:06 +0100
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=andrew.cooper3@xxxxxxxxxx; spf=Pass smtp.mailfrom=Andrew.Cooper3@xxxxxxxxxx; spf=None smtp.helo=postmaster@xxxxxxxxxxxxxxx; dmarc=pass (p=none dis=none) d=citrix.com
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Mon, 11 May 2020 15:01:17 +0000
  • Ironport-sdr: jL9iz8iYybZHUJ5sG5imbQX6g2fRPuHHX8nws8tUowYFFhhDaNmcy8wvrW/uPKnsInraGhGRVn p8IdgAXy+CTdOJopA7ya8vK+X6YXepVb0n/+lpid+6IWCoQPuEuu1E1BLkfGg2R4qEcepaUIUx UutQM31k19JP1wI9u39btDyq11d+ISYi6B0/+V8nfV+X1zju3TXdqOxwJIw4h+SUUSQzMA2elD REcpry8gP4W2REgenGp7LIEM8wTg+8toLFt0c2ZA4FHjFNncrW/dp4lg8I5QGkN/NhSKiz/XhT P3k=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 04/05/2020 14:08, Jan Beulich wrote:
> On 02.05.2020 00:58, Andrew Cooper wrote:
>> For one, they render the vector in a different base.
>>
>> Introduce X86_EXC_* constants and vec_name() to refer to exceptions by their
>> mnemonic, which starts bringing the code/diagnostics in line with the Intel
>> and AMD manuals.
> For this "bringing in line" purpose I'd like to see whether you could
> live with some adjustments to how you're currently doing things:
> - NMI is nowhere prefixed by #, hence I think we'd better not do so
>   either; may require embedding the #-es in the names[] table, or not
>   using N() for NMI

No-one is going to get confused at seeing #NMI in an error message.  I
don't mind jugging the existing names table, but anything more
complicated is overkill.

> - neither Coprocessor Segment Overrun nor vector 0x0f have a mnemonic
>   and hence I think we shouldn't invent one; just treat them like
>   other reserved vectors (of which at least vector 0x09 indeed is one
>   on x86-64)?

This I disagree with.  Coprocessor Segment Overrun *is* its name in both
manuals, and the avoidance of vector 0xf is clearly documented as well,
due to it being the default PIC Spurious Interrupt Vector.

Neither CSO or SPV are expected to be encountered in practice, but if
they are, highlighting them is a damn-sight more helpful than pretending
they don't exist.

~Andrew



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.