>BTW, I think that turning on debugger from qemu is a dangerous action,
>from security point of view. Once the gdbserver is started, anybody
>can connect to it (with gdb) and modify VM memory in anyway he wants
>(like overwrite kernel with malicious code). The problem why this is
>feasible is becau
Bugs item #1744028, was opened at 2007-06-27 09:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1744028&group_id=180599
Please note that this message will contain a full copy
I am building a system that is using virtualization for partitioning,
running 2 Linux images.
The guest needs direct access to IB interfaces. This will be exclusive
access, not shared with any other domain. This is easily done on Xen,
I am not sure I understand if (or how) it can be done on KVM.
I was kinda wondering if anyone out there had done testing with
multiple kvm's on a single box and how kvm handles when running lots
of guest OS's (say 10+).
Should I keep the number of kvm's strictly less than the number of cores?
Has there been any testing bringing up 10+ kvm's on a single box?
>I was kinda wondering if anyone out there had done testing with
>multiple kvm's on a single box and how kvm handles when running lots
>of guest OS's (say 10+).
Kvm has been used with 20 VMs and even 40 over a single host dual/quad
core). It also has been tested with ballooning, using over commit
>I am building a system that is using virtualization for partitioning,
>running 2 Linux images.
>
>The guest needs direct access to IB interfaces. This will be exclusive
>access, not shared with any other domain. This is easily done on Xen,
>I am not sure I understand if (or how) it can be done on
On Wed, 2007-06-27 at 08:08 -0700, Dor Laor wrote:
> >I am building a system that is using virtualization for partitioning,
> >running 2 Linux images.
> >
> >The guest needs direct access to IB interfaces. This will be exclusive
> >access, not shared with any other domain. This is easily done on X
On 6/26/07, Gregory Haskins <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-06-25 at 18:08 -0400, Avi Kivity wrote:
> > > Note that there is another standard that would allow us to use built-in
> > > routing without ACPI/IOAPIC: MSI. I know the battle over
> > > virtual-bus-rendering is still raging w.r
On 6/27/07, Dor Laor <[EMAIL PROTECTED]> wrote:
> >BTW, I think that turning on debugger from qemu is a dangerous action,
> >from security point of view. Once the gdbserver is started, anybody
> >can connect to it (with gdb) and modify VM memory in anyway he wants
> >(like overwrite kernel with mal
>On 6/27/07, Dor Laor <[EMAIL PROTECTED]> wrote:
>> >BTW, I think that turning on debugger from qemu is a dangerous
action,
>> >from security point of view. Once the gdbserver is started, anybody
>> >can connect to it (with gdb) and modify VM memory in anyway he wants
>> >(like overwrite kernel wit
Willow Schlanger wrote:
> Hi, in vmx_vcpu_setup() is this code:
>
> vmcs_writel(GUEST_IDTR_BASE, 0);
> vmcs_write32(GUEST_IDTR_LIMIT, 0x);
>
> But if you use SIDT on a real processor, after boot-up, you will see the
> real-mode base is in fact 0, but the limit is 0x3ff. That is, in
On 6/28/07, Dor Laor <[EMAIL PROTECTED]> wrote:
> >On 6/27/07, Dor Laor <[EMAIL PROTECTED]> wrote:
> >> >BTW, I think that turning on debugger from qemu is a dangerous
> action,
> >> >from security point of view. Once the gdbserver is started, anybody
> >> >can connect to it (with gdb) and modify V
12 matches
Mail list logo
