Loading ...
Sorry, an error occurred while loading the content.

Re: [hackers-il] Xen

Expand Messages
  • Muli Ben-Yehuda
    ... Which beast? Linux or Xen? ... I m not quite sure I m following, but in general there are three ways of virtualizing code if your CPU doesn t support it: -
    Message 1 of 3 , Oct 23, 2005
    • 0 Attachment
      On Sat, Oct 22, 2005 at 12:23:46PM -0700, Omer Shapira wrote:

      > A layman's question - what is the easiest way for
      > someone who doesn't remember much of a linux kernel
      > (me) to start tweaking the beast?

      Which beast? Linux or Xen?

      > In addition, I am very interested on how modern
      > compilers can cope with virtualized CPUs.
      > I assume that cpu calls caused by virtualized
      > resources can get the CPU frontend insane quite fast.
      > Correct me if I am wrong.

      I'm not quite sure I'm following, but in general there are three ways
      of virtualizing code if your CPU doesn't support it:

      - rewrite the priviledged bits at run time (VMWare's dynamic rewriting
      of executing code before it executes)
      - rewrite the priviledged bits at your leisure, then recompile (Xen's
      - have your toolchain rewrite the priviledged bits when you compile
      the code (L4 group's afterburner project - see

      All of these approaches concentrate on running non-priviledged code
      natively (unlike CPU emulators like Bochs and QEMU, which translate
      and emulate all instructions) and only deal with priviledged

      Does this answer the question?

      > In addition, I am intrigued by a problem of providing
      > networking hardware/software necessary for efficient
      > virutalization of network devices.

      Ah, now that's a question I am wont to discuss at length for multiple
      hours at a time, and have been known to do so :-)

      > Consider, for example, a switch chip (an
      > uber-super-hyper NIC) that does TCP session handshake
      > offloading, and interrupts only on sessions that are
      > not to be bridged, but are intended for the device
      > itself. Either the silicon intended for the port
      > buckets is multiplied (expensive, dollar-wise), or
      > lots of interrupts are delivered to the CPU
      > (expensive, cycle-wise).

      If you're at a situation where you are likely to have lots of
      interrupts delivered, you'd probably switch to chip to polling mode
      (a-la NAPI in Linux).

      Here's a question for discussion: does virtualization support *in
      devices* make sense? or should we stick with "regular devices" and let
      the software multiplex it?

      > I admit these questions have little with ethics of
      > software licensing as opposed to licencing of software
      > ethics, and are rather (paraphrasing nyh) examples fo
      > "engineering mumbo-jumbo", but these questions bug me
      > lately.

      We now return you to your regularly scheduled shlomifogram!

      Muli Ben-Yehuda
      http://www.mulix.org | http://mulix.livejournal.com/
    Your message has been successfully submitted and would be delivered to recipients shortly.