All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
	Feng Wu <feng.wu@intel.com>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH v2 09/10] x86/irqs: Move interrupt-stub generation out of C
Date: Fri, 16 May 2014 16:22:42 +0100	[thread overview]
Message-ID: <53762D42.6060303@citrix.com> (raw)
In-Reply-To: <537645A802000078000132F3@mail.emea.novell.com>

On 16/05/14 16:06, Jan Beulich wrote:
>>>> On 16.05.14 at 12:39, <andrew.cooper3@citrix.com> wrote:
>>>>
>>>>
>> --- a/xen/arch/x86/x86_64/entry.S
>> +++ b/xen/arch/x86/x86_64/entry.S
>> @@ -475,6 +475,12 @@ ENTRY(common_interrupt)
>>          callq do_IRQ
>>          jmp ret_from_intr
>>  
>> +ENTRY(reserved_exception)
>> +        SAVE_ALL CLAC
>> +        movq %rsp,%rdi
>> +        callq do_reserved_exception
>> +        jmp ret_from_intr
> Sadly this still doesn't take care of auto-detecting whether an error
> code got pushed.

It is not supposed to.

Each reserved exception has its own automatically generated stub which
pushes its trap value, so do_reserved_exception() can identify which
trap has been unexpectedly triggered.

Currently there are no reserved exceptions which push an error code.  I
will leave a warning comment by the generation code to take care with
the first pushq $0.

>
> Also - is there a particular reason you don't have this go though
> handle_exception?

I hadn't considered that.  Its a good idea.  We can:

* Automatically generate the reserved entry point, directed at
handle_exception
* Fully populate the exception_table, with several labels going towards
do_reserved_exception.
* Treat the double fault entry in exception_table as reserved.  We
certainly don't want to enter through it.

>
>> @@ -717,13 +713,13 @@ ENTRY(exception_table)
>>          .quad do_invalid_op
>>          .quad do_device_not_available
>>          .quad BAD_VIRT_ADDR         /* double_fault, IST entry */
>> -        .quad do_coprocessor_segment_overrun
>> +        .quad BAD_VIRT_ADDR         /* coproc_seg_overrun, reserved */
>>          .quad do_invalid_TSS
>>          .quad do_segment_not_present
>>          .quad do_stack_segment
>>          .quad do_general_protection
>>          .quad do_page_fault
>> -        .quad do_spurious_interrupt_bug
>> +        .quad BAD_VIRT_ADDR         /* PIC IRQ7 spurious, reserved */
> And the comment here didn't get much (if at all) adjusted either.

What about "Default PIC spurious interrupt, architecturally reserved" ?

>
>> --- /dev/null
>> +++ b/xen/arch/x86/x86_64/irqgen.S
>> @@ -0,0 +1,52 @@
>> +/* Automatically generated interrupt entry points */
>> +#include <asm/processor.h>
>> +#include <irq_vectors.h>
>> +
>> +.section ".init.rodata", "a", @progbits
>> +
>> +/* Table of automatically generated entry points.  One per vector. */
>> +GLOBAL(autogen_entrypoints)
>> +
>> +/* pop into the .init.rodata section and record an entry point. */
>> +.macro entrypoint ent
>> +    .pushsection ".init.rodata", "a", @progbits
> Actually it's quite pointless to repeat the attributes - they can't be
> different than in the first section declaration anyway.
>
> Also I think this more legible version would now better go into entry.S
> rather than having a new file for it.
>
> Jan
>

Sure.

~Andrew

  reply	other threads:[~2014-05-16 15:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-16 10:39 [PATCH v2 00/10] x86: Improvements to trap handling Andrew Cooper
2014-05-16 10:39 ` [PATCH v2 01/10] x86/traps: Mnemonics for system descriptor types Andrew Cooper
2014-05-16 10:39 ` [PATCH v2 02/10] x86/traps: Make panic and reboot paths safe during early boot Andrew Cooper
2014-05-16 10:39 ` [PATCH v2 03/10] x86/traps: Make the main trap handlers safe for use early during Xen boot Andrew Cooper
2014-05-16 10:39 ` [PATCH v2 04/10] x86/misc: Early cleanup Andrew Cooper
2014-05-16 10:39 ` [PATCH v2 05/10] x86/traps: Functional prep work Andrew Cooper
2014-05-16 10:39 ` [PATCH v2 06/10] x86/boot: Install trap handlers much earlier on boot Andrew Cooper
2014-05-16 10:39 ` [PATCH v2 07/10] x86/boot: Correct CR4 setup on APs Andrew Cooper
2014-05-16 10:39 ` [PATCH v2 08/10] x86/boot: Drop pre-C IDT patching Andrew Cooper
2014-05-16 10:39 ` [PATCH v2 09/10] x86/irqs: Move interrupt-stub generation out of C Andrew Cooper
2014-05-16 15:06   ` Jan Beulich
2014-05-16 15:22     ` Andrew Cooper [this message]
2014-05-16 15:30       ` Jan Beulich
2014-05-16 10:39 ` [PATCH v2 10/10] x86/misc: Post cleanup Andrew Cooper
2014-05-16 15:10   ` Jan Beulich

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=53762D42.6060303@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=feng.wu@intel.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.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.