Your answer is let me to see the file (realview.c),but i use the arm's kernel
is Versatile.
At qemu/hw/versatilepb.c the file i ever change some code
static QEMUMachine versatilepb_machine = {
.name = "versatilepb",
.desc = "ARM Versatile/PB (ARM926EJ-S)",
.init = vpb_init,
Arnd Bergmann wrote:
Well, the difference matters from a security perspective. The sudo
script that Avi suggested just means that you can guarantee you don't
introduce any security holes through a suid executable. Fortunately,
it does not impact the contents of your helper either, only the
instal
David Woodhouse wrote:
On Tue, 2009-11-03 at 18:28 -0600, Anthony Liguori wrote:
The most common use of -net tap is to connect a tap device to a bridge. This
requires the use of a script and running qemu as root in order to allocate a
tap device to pass to the script.
Does it?
Tap d
On Saturday 07 November 2009, Anthony Liguori wrote:
> Avi Kivity wrote:
> > On 11/07/2009 11:14 AM, Avi Kivity wrote:
> >> I'd welcome -net bridge as one of them. But we shouldn't try to
> >> invent access control systems or install suid helpers.
> >
> > We can make the helper a script that does
On Tue, 2009-11-03 at 18:28 -0600, Anthony Liguori wrote:
> The most common use of -net tap is to connect a tap device to a bridge. This
> requires the use of a script and running qemu as root in order to allocate a
> tap device to pass to the script.
Does it?
Tap devices can be created (and co
On Sat, Nov 7, 2009 at 5:11 PM, Blue Swirl wrote:
[...]
>> Unless I missed something you didn't commit Glauber's patch.
>
> What's c169998802505c244b8bcad562633f29de7d74a4 then?
My bad, I updated and didn't notice you had applied further
modifications. I seriously lack the commit mail notificati
On Sat, Nov 7, 2009 at 6:02 PM, Laurent Desnogues
wrote:
> On Sat, Nov 7, 2009 at 9:40 AM, Blue Swirl wrote:
> [...]
>> Thanks, applied. While testing I noticed that the poor x86 emulator
>> does not survive even five system_resets until BIOS refuses to boot.
>> This happens without your patch. I
On Sat, Nov 7, 2009 at 9:40 AM, Blue Swirl wrote:
[...]
> Thanks, applied. While testing I noticed that the poor x86 emulator
> does not survive even five system_resets until BIOS refuses to boot.
> This happens without your patch. In comparison, I see no problems
> resetting Sparc32, Sparc64 or P
On Sat, Nov 7, 2009 at 1:09 AM, Gerd Hoffmann wrote:
> Hi,
>
> http://repo.or.cz/w/qemu/kraxel.git/shortlog/refs/heads/scsi.v6
>
> What is in there?
>
> (1) Reworked scsi data structures. There is a SCSIRequest struct now.
> (2) Restructed emulation in the scsi-disk driver.
> (3) New interfac
Signed-off-by: David Woodhouse
diff --git a/block/parallels.c b/block/parallels.c
index 0b64a5c..63b6738 100644
--- a/block/parallels.c
+++ b/block/parallels.c
@@ -119,7 +119,8 @@ fail:
static inline int seek_to_sector(BlockDriverState *bs, int64_t sector_num)
{
BDRVParallelsState *s = bs-
Avi Kivity wrote:
On 11/07/2009 11:14 AM, Avi Kivity wrote:
I'd welcome -net bridge as one of them. But we shouldn't try to
invent access control systems or install suid helpers.
We can make the helper a script that does
exec sudo /the/real/helper "$@"
so a user can add it to /etc/sudoers
Avi Kivity wrote:
Running qemu directly from the command line is absolutely an
important use case.
Where does this requirement come from?
For most of qemu's lifetime, this was the only option. The current
graphical front ends only support a subset of qemu's features and qemu's
target arch
Avi Kivity wrote:
So it's equivalent to enabling dirty tracking during live migration.
In my mind, if the cost associated with hot plug is a fraction of the
cost of live migration, we're in good shape.
I don't see why. Live migration is pretty expensive, but that doesn't
mean NIC hotplug sh
2009/11/7 m9807418 :
> When I used qemu-system-arm and the -smp option.
> I key -smp 2.
> It have a message ""Number of SMP cpus requested (2), exceeds max cpus
> supported by machine `Versatile' (1) "
> which files of the qemu source code can i change?
> And the change can let me emulator arm's m
On 11/07/2009 12:44 PM, Jamie Lokier wrote:
Aiee - what's the plan? Can a running KVM be forked, as in into two
separate processes to run the forked guests in parallel, or not?
kvm fds do not support fork(). Nothing prevents you from stopping the
guest, reading guest state, fork()ing, an
Avi Kivity wrote:
> So vfork() is required, or in light of its man page and glowing
> recommendations from the security people,
vfork() on Linux is fine to use, as long as you respect it's unwritten
requirements :-)
In a multithreaded program: you can start by spawning a thread for the
sole purp
On 11/07/2009 11:14 AM, Avi Kivity wrote:
I'd welcome -net bridge as one of them. But we shouldn't try to
invent access control systems or install suid helpers.
We can make the helper a script that does
exec sudo /the/real/helper "$@"
so a user can add it to /etc/sudoers and get pre-authen
On 11/06/2009 06:09 PM, Anthony Liguori wrote:
No, it's an argument against fork() of large programs.
After putting together a work around, I'm starting to have my doubts
about how real of a problem this is.
You're only write protecting memory, correct?
The kernel write protects qemu me
On 11/06/2009 04:19 PM, Anthony Liguori wrote:
Avi Kivity wrote:
Instead of doing silly things into qemu, if there is concern about
this, then it should be fixed in Linux properly.
Of course there is concern about it, and you don't have to do
anything silly to qemu to avoid it. Just not call
On Fri, Nov 6, 2009 at 10:41 PM, Glauber Costa wrote:
> On Fri, Nov 06, 2009 at 09:01:45PM +0200, Blue Swirl wrote:
>> On Fri, Nov 6, 2009 at 8:43 PM, Laurent Desnogues
>> wrote:
>> > On Fri, Nov 6, 2009 at 7:11 PM, Glauber Costa wrote:
>> >> On Fri, Nov 06, 2009 at 08:05:40PM +0200, Blue Swirl
20 matches
Mail list logo
