Skip to content
Snippets Groups Projects
Select Git revision
  • simonci
  • vanillaCI
  • ibr/cpu-event-worker-leanstore-integration
  • ibr/cpu-event-worker
  • revert-dbd4f905
  • ibr/event-sched
  • job-queue
  • debug-shed-with-sclicing-and-multiple-cores
  • pr/sched-rr
  • ibr/sched-rr
  • dietrich/rwlock
  • dietrich/tcb-shrink
  • dietrich/memory-compression
  • master default protected
  • job-queue-load-balance
  • vldb24-vision
  • ipv6
  • riscv64
  • stable/v0.19
  • static-elf
  • v0.57.0
  • v0.56.0
  • v0.55.0
  • v0.54.0
  • v0.53.0
  • v0.52.0
  • v0.51.0
  • v0.24
  • v0.23
  • v0.22
  • v0.21
  • v0.20
  • v0.19
  • v0.18
  • v0.17
  • v0.16
  • v0.15
  • v0.15-rc3
  • v0.15-rc1
  • v0.14
40 results
Search by author
  • Any Author
  • Christian Dietrich Christian Dietrich dietrich
  • Niklas Gollenstede Niklas Gollenstede gollenst
  • Sebastian Kosak kosak
  • Simon-Nassim Kanoun kanoun
  • Sören Tempel Sören Tempel tempel
5 authors
  1. Dec 20, 2013
  3. Dec 19, 2013
  5. Dec 18, 2013
  7. Dec 17, 2013
  9. Dec 16, 2013
  11. Dec 11, 2013
  13. Dec 09, 2013
  15. Dec 08, 2013
    • Glauber Costa's avatar
      xen: disable pvclock for more than 32 CPUs · 0ddd6ef1
      Glauber Costa authored 
      
Xen's shared info contains hardcoded space for only 32 CPUs.  Because we use
those structure to derive timing information, we would be basically accessing
random memory after that. This is very hard to test and trigger, so what I'd
did to demonstrate I was right (although that wasn't really needed, math could
be used for that...) was to print the first timing information a cpu would
produce. I could verify that the timing on CPUs > 32 was behind in time than
the time produced in CPUs < 32.

It is possible to move the vcpu area to a different location, but this is a
relatively new feature of the Xen Hypervisor: Amazon won't support it. So
we need a disable path anyway. I will open up an issue for somebody to implement
that support eventually.

Another user of the vcpu structure is interrupts. But for interrupts the story
is easier, since we can select which CPUs we can take interrupts at, and only
take them in the first 32 CPUs. In any case, we're taking them all in CPU0 now,
so already under control

Signed-off-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      0ddd6ef1
  17. Dec 06, 2013
    • Asias He's avatar
      virtio: Fix vring::used_ring_is_half_empty() calculation · c62c9dd8
      Asias He authored 
      
This patch fixes:

- The order of _used_ring_host_head and _used->_idx, the latter is more
  advanced than the former.
- The unwanted promotion to "int"

Pekka wrote:

   However, on the right-hand side, the expression type in master
   evaluates to "int" because of that innocent-looking constant "2" and
   lack of parenthesis after the cast.  That will also force the
   left-hand side to promote to "int".

   And no, I really don't claim to follow integer promotion rules so I
   used typeid().name() verify what the compiler is doing:

   [penberg@localhost tmp]$ cat types.cpp
   #include <typeinfo>
   #include <stdint.h>
   #include <cstdio>

   using namespace std;

   int main()
   {
       unsigned int _num = 1;

       printf("int                = %s\n", typeid(int).name());
       printf("uint16_t           = %s\n", typeid(uint16_t).name());
       printf("(uint16_t)_num/2)  = %s\n", typeid((uint16_t)_num/2).name());
       printf("(uint16_t)(_num/2) = %s\n", typeid((uint16_t)(_num/2)).name());
   }
   [penberg@localhost tmp]$ g++ -std=c++11 -Wall types.cpp
   [penberg@localhost tmp]$ ./a.out
   int                = i
   uint16_t           = t
   (uint16_t)_num/2)  = i
   (uint16_t)(_num/2) = t

Signed-off-by: default avatarAsias He <asias@cloudius-systems.com>
Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
      c62c9dd8