All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Gerd Hoffmann <kraxel@suse.de>
Cc: Virtualization Mailing List <virtualization@lists.osdl.org>
Subject: Re: paravirt & xen & SMP
Date: Thu, 11 Jan 2007 15:13:04 -0800	[thread overview]
Message-ID: <45A6C480.6040104@goop.org> (raw)
In-Reply-To: <45A64CA7.80209@suse.de>

Gerd Hoffmann wrote:
> Well, after reading the code a bit more it seems the intention is to
> call the function in a row with others, have stuff queued up (in case
> lazy_mode == PARAVIRT_LAZY_CPU is set) and update everything in one go
> then.  I don't think that makes sense for that function as it isn't
> performance-critical.  It is called on boot and cpu bringup (well, not
> yet) only, right?
>   

Yes, that's right.  While its not performance critical in itself, the
idea was that if it were in a stream of other deferred cpu-state
updates, then it should happen in the appropriate order.   But in
practice this is mainly to make a context switch a single hypercall, so
the most important ones are stack-switch followed by 3x
update_descriptor (for TLS).

> We have a simliar issue for xen_write_gdt_entry() btw, it calls
> mc_flush() which doesn't work too.  I've fixed it that way:
>
> @@ -761,7 +762,13 @@ static asmlinkage void __init xen_start_
>         /* set up PDA descriptor */
>         pack_descriptor(&low, &high, (unsigned)&boot_pda,
> sizeof(boot_pda)-1,
>                         0x80 | DESCTYPE_S | 0x02, 0);
> +#if 0
>         xen_write_gdt_entry(cpu_gdt_table, GDT_ENTRY_PDA, low, high);
> +#else
> +       if (HYPERVISOR_update_descriptor(virt_to_machine(cpu_gdt_table +
> GDT_ENTRY_PDA).maddr,
> +                                        (u64)high << 32 | low))
> +               BUG();
> +#endif
>
>         /* set up %gs and init Xen parts of the PDA */
>         asm volatile("mov %0, %%gs" : : "r" (__KERNEL_PDA) : "memory");
>
> [ gna, thunderbird isn't great for sending patches inline, you should
>   get the idea though ... ]
>   

Yeah, that's ugly, but I guess it will do for now.

(You can inline patches without damage in thunderbird if you paste them
as "preformat")

    J

      reply	other threads:[~2007-01-11 23:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-10 15:23 paravirt & xen & SMP Gerd Hoffmann
     [not found] ` <27c823430701100818i5ec586ffm65d5678f4fe1bbea@mail.gmail.com>
2007-01-10 16:27   ` Gerd Hoffmann
2007-01-10 18:48 ` Jeremy Fitzhardinge
2007-01-11 14:41   ` Gerd Hoffmann
2007-01-11 23:13     ` Jeremy Fitzhardinge [this message]

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=45A6C480.6040104@goop.org \
    --to=jeremy@goop.org \
    --cc=kraxel@suse.de \
    --cc=virtualization@lists.osdl.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.