On Wed, Nov 15, 2006 at 01:03:34PM -0600, Anthony Liguori wrote:
>
> >The scenario here is a compromised guest attempting to harm a host such
> >as Xen.
>
> The only "harm" done to a host is that the process will take as much CPU
> as it can get. This is really only a problem in Xen because the
On Wed, Nov 15, 2006 at 03:02:02PM +, Paul Brook wrote:
> > However, chips such as rtl8139 should never
> > do MMIO in this case (the real hardware would never allow that to occur)
>
> Really? Why wouldn't it work on real hardware?
For rtl8139 it would cause a Master Abort.
Cheers,
--
Visit
> However, chips such as rtl8139 should never
> do MMIO in this case (the real hardware would never allow that to occur)
Really? Why wouldn't it work on real hardware?
Paul
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mail
On Wed, Nov 15, 2006 at 07:55:48AM +, Keir Fraser wrote:
>
> > I'm not suggesting that we change all existing users of cpu_physical_*
> > to a new interface that only accessed RAM. However, for cases where it
> > is obvious that only system RAM is intended (e.g., rtl8139), it makes
> > sense t
Hello,
I'm trying to enable SMP support. The guest OS is DragonFly,
SMP-enabled kernel. QEmu accelerator module is not loaded.
The kernel does its initialization (device probes) but qemu crashes
near the end, I guess when the kernel tries to activate the second virtual
CPU, just before creating t
Hi..
> Hello everybody
>
> Today I boot my FC2 disk image along with 2.6.17-mm6 kernel using
> this command line:
> qemu -hda ./fc2.img -m 64 -net none -kernel
> /mnt/linux/linux-2.6.17-mm6-HZ1000/arch/i386/boot/bzImage -no-kqemu
> -append root=/dev/hda1
Following up my own post, I revealed that
