Re: [Qemu-devel] [PATCH] v3: don't call reset functions on cpu initialization
On Fri, Nov 6, 2009 at 10:41 PM, Glauber Costa glom...@redhat.com 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 laurent.desnog...@gmail.com wrote: On Fri, Nov 6, 2009 at 7:11 PM, Glauber Costa glom...@redhat.com wrote: On Fri, Nov 06, 2009 at 08:05:40PM +0200, Blue Swirl wrote: On Thu, Nov 5, 2009 at 6:05 PM, Glauber Costa glom...@redhat.com wrote: [...] --- a/target-i386/helper.c +++ b/target-i386/helper.c @@ -1885,7 +1885,9 @@ CPUX86State *cpu_x86_init(const char *cpu_model) return NULL; } mce_init(env); +#ifdef CONFIG_USER_ONLY cpu_reset(env); +#endif Please push the call to *-user/main.c, just after call to cpu_init(). I'd prefer it that way too. But cpu_reset is also called in some other places, and Laurent suggested me to to this way. Yes, you'd have to remove all calls to cpu_reset from all CPUs. And also add a call to cpu_reset to cpu_copy. I don't really know much about -user, so I'm fine with whatever you guys agree on. I honestly don't care that much as long as all targets still work in user mode :-) The aim was to make Glauber's patch less intrusive. Given that only the new calls to cpu_reset are important and the removals are much less so (double reset shouldn't be a problem), the least intrusive version would be to just add the new calls and do the clean up later. Which IMHO, pretty much means apply it this way, and then later on move the reset functions elsewhere for -user, if one wants to. 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 PPC.
Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
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 helpers while it's running. This is unacceptable. We use helpers in multiple places today. We use a helper to configure a tap device that we've allocated, we use it for the exec: protocol for live migration, etc. I hope none of these are ever used in production systems. Taps should come pre-configured from management (no need for management to ask qemu to run a management helper when management could run that helper more easily itself). exec: migration is also pointless when you can pass and fd and do any proxying required. Running qemu directly from the command line is absolutely an important use case. Where does this requirement come from? We probably have different ideas of what a desktop user means. In my mind, a desktop user doesn't switch to the monitor and type 'eject', he clicks a button with an eject icon and a text caption underneath. He doesn't run qemu-img create -f qcow2 /images/vm1.img, he clicks 'New Virtual Machine Wizard' and answers all the tedious questions. And he absolutely doesn't type qemu-system-x86_64 -enable-kvm -m 1G -smp 2 -net nic,macaddr=aa:00:00:00:00:01 /images/vm1.img -cdrom /images/iso/en_us_blah.iso, instead he clicks My\ New\ Virtual\ Machine\ \(copy\).qemu on his desktop. A desktop user should not need things like libvirt and virt-manager. virt-mananger is miles ahead of where you're aiming. I'd like to a proper same-process graphical UI client. But I don't think this list is the place to create it. I don't think we have either the skills or the patience; also there's room for more than one. We should focus on making it easy to write one; that involves exporting the display surface in an embeddable non-vnc way and making everything controllable via QObjects (perhaps through the monitor, perhaps through bindings for scripting languages. If it cannot be fixed in the kernel, we'll have to work around it in userspace. We can introduce our own spawn() function that works by fork()'ing very early and listening on a socketpair. This will sit reading from the socket waiting for commands to exec. Using a unix socket, we can pass fds that get inherited which we can't do with system(). Or we can admit to ourselves that qemu is too complex to be directly controlled by a user. It's good to have an easy to use command line for developers and power users; I'd welcome -net bridge as one of them. But we shouldn't try to invent access control systems or install suid helpers. Mainstream use needs to involve some management agent which does authentication and privileged configuration (it was already established that the the hotplug equivalent of -net bridge is racy if any configuration is required). I'd rather not have a program running with elevated privileges when it not needed. suid helpers are dangerous whenever they are on disk; daemons are dangerous only when running. A suid helper equivalent to a root daemon from a security perspective. It's just long running vs. transient. They are not equivalent. suid helpers are dangerous whenever they are on disk; daemons are dangerous only when running. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
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 memory, and kvm write protects shadow page table entries. Live migration only does the second. 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 should be. Deployments where live migration isn't a concern (for example, performance critical guests that use device assignment) don't suffer the live migration penalty so they shouldn't expect to see a gratuitous NIC hotplug penalty that is a fraction of that. Come to think of that, we probably have some fork() breakage with device assignment since we can't write protect pages assigned to the iommu. It's not likely that a 16GB guest is going to write-fault in it's entirely memory range immediately. In fact, it's likely to be amortized over a very long period of time so I have a hard time believing this is really an issue in practice. It depends on the workload. With large pages in both host and guest you can touch 10M pages/sec without difficulty. Once you write protect them this drops to maybe 0.3M pages/sec. The right workload will suffer pretty badly from this. Arguably, it's a much bigger problem for live migration. It is. I once considered switching live migration to shadow pte dirty bit tracking instead of write protection, but ept doesn't have dirty bits, so this will only help a minority of deployments by the time it reaches users. So vfork() is required, or in light of its man page and glowing recommendations from the security people, we can mark guest memory as shared on fork and use plain fork(), like we do for pre mmu notifier kernels. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
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-authenticated configuration. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
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 purpose of spawning a process. Call vfork() from the new thread. Then a slow exec() call won't delay the rest of the program, because it's only blocking the thread you created. we can mark guest memory as shared on fork and use plain fork(), like we do for pre mmu notifier kernels. 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? Thanks, -- Jamie
Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
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, and creating a new VM in the child with the same state, then restarting both instances. qemu in general cannot be forked; the two instances would trample on each others disk images, host network connections (i.e. vnc, X, the monitor), guest network connections, etc. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Re: [Qemu-devel]question:arm's mutli-core emulator
2009/11/7 m9807418 m9807...@mail.ntust.edu.tw:
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 multi-core.
1. Your question has nothing to do with the development of qemu, so
don't be surprised when you don't get too many responses.
2. See qemu/hw/realview.c
if (!cpu_model)
cpu_model = arm926;
/* FIXME: obey smp_cpus. */
if (strcmp(cpu_model, arm11mpcore) == 0) {
ncpu = 4;
} else {
ncpu = 1;
}
Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
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 architecture types. qemu is more than just KVM accelerated x86 guests. I also disagree that only developers are interested in using qemu directly. There are a lot of power users who also use qemu directly. A desktop user should not need things like libvirt and virt-manager. virt-mananger is miles ahead of where you're aiming. I'd like to a proper same-process graphical UI client. But I don't think this list is the place to create it. I don't think we have either the skills or the patience; also there's room for more than one. We should focus on making it easy to write one; that involves exporting the display surface in an embeddable non-vnc way and making everything controllable via QObjects (perhaps through the monitor, perhaps through bindings for scripting languages. If it cannot be fixed in the kernel, we'll have to work around it in userspace. We can introduce our own spawn() function that works by fork()'ing very early and listening on a socketpair. This will sit reading from the socket waiting for commands to exec. Using a unix socket, we can pass fds that get inherited which we can't do with system(). Or we can admit to ourselves that qemu is too complex to be directly controlled by a user. It's good to have an easy to use command line for developers and power users; I'd welcome -net bridge as one of them. But we shouldn't try to invent access control systems or install suid helpers. Mainstream use needs to involve some management agent which does authentication and privileged configuration (it was already established that the the hotplug equivalent of -net bridge is racy if any configuration is required). I disagree about the role a management app should play. For a casual user, a management app really should not be needed. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
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 and get pre-authenticated configuration. The key point of the helper here is that you pass an fd to a socketpair and you then receive an fd over that socket. What the helper does is really less important. Whether it's a script like you suggest or something like I proposed doesn't matter from a qemu perspective. Whether the qemu-bridge-helper should live in qemu or somewhere else is a valid thing to discuss. In my next posting, I'll have things restructured to separate out the two so that they two series can be considered independently. Regards, Anthony Liguori
[Qemu-devel] [PATCH] Fix 32-bit overflow in parallels image support
Signed-off-by: David Woodhouse david.woodho...@intel.com
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-opaque;
-uint32_t index, offset, position;
+uint32_t index, offset;
+uint64_t position;
index = sector_num / s-tracks;
offset = sector_num % s-tracks;
@@ -128,7 +129,7 @@ static inline int seek_to_sector(BlockDriverState *bs,
int64_t sector_num)
if ((index s-catalog_size) || (s-catalog_bitmap[index] == 0))
return -1;
-position = (s-catalog_bitmap[index] + offset) * 512;
+position = (uint64_t)(s-catalog_bitmap[index] + offset) * 512;
//fprintf(stderr, sector: %llx index=%x offset=%x pointer=%x
position=%x\n,
// sector_num, index, offset, s-catalog_bitmap[index], position);
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
Re: [Qemu-devel] [sneak preview] major scsi overhaul
On Sat, Nov 7, 2009 at 1:09 AM, Gerd Hoffmann kra...@redhat.com 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 interface for HBA = SCSIDevice interaction: * building on the new SCSIRequest struct. * the silly read_data/write_data ping-pong game is gone. * support for scatter lists and zerocopy I/O is there. Cool. (4) Added support for the new interface to scsi-disk and scsi-generic. (5) Switched esp and usb-storage to the new interface. * fixed usb-storage state engine along the way. And, no, a backport to stable isn't going to happen. With the new interface state tracking is simpler and easier to get right. (6) A bunch of misc fixes and improvements. What needs to be done? (1) Better patch descriptions. (2) Submit patches to the list for review. (3) Switch over lsi to the new interface. (4) Zap old interface, killing tons of dead code. (5) Final cleanups. In general the commits look good, there are many obviously correct cleanups. However, what happens to the DPRINTFs, it looks like they are removed in the process? You are also moving the compilation to Makefile.hw, which is not exactly an improvement. Is this needed because of the QEMUIOVector stuff?
Re: [Qemu-devel] [PATCH] v3: don't call reset functions on cpu initialization
On Sat, Nov 7, 2009 at 9:40 AM, Blue Swirl blauwir...@gmail.com 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 PPC. Unless I missed something you didn't commit Glauber's patch. So now in user mode cpu_reset differs for i386, SPARC and PPC, and all other targets. On top of that you didn't add a call to cpu_reset from cpu_copy which also calls cpu_init. Are you sure it's OK? Laurent
Re: [Qemu-devel] [PATCH] v3: don't call reset functions on cpu initialization
On Sat, Nov 7, 2009 at 6:02 PM, Laurent Desnogues laurent.desnog...@gmail.com wrote: On Sat, Nov 7, 2009 at 9:40 AM, Blue Swirl blauwir...@gmail.com 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 PPC. Unless I missed something you didn't commit Glauber's patch. What's c169998802505c244b8bcad562633f29de7d74a4 then? So now in user mode cpu_reset differs for i386, SPARC and PPC, and all other targets. No, for example MIPS cpu_reset is still called only once from cpu_mips_init. On top of that you didn't add a call to cpu_reset from cpu_copy which also calls cpu_init. Are you sure it's OK? It's not, I forgot to add that, sorry.
Re: [Qemu-devel] [PATCH] v3: don't call reset functions on cpu initialization
On Sat, Nov 7, 2009 at 5:11 PM, Blue Swirl blauwir...@gmail.com 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 notifications :-) Laurent
Re: [Qemu-devel] [PATCH 4/4] Add support for -net bridge
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 configured) in advance, and can be chowned so that they can be opened by an otherwise unprivileged user (or group). You don't need root privileges to use a tap device. -- dwmw2
Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
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 exec sudo /the/real/helper $@ so a user can add it to /etc/sudoers and get pre-authenticated configuration. The key point of the helper here is that you pass an fd to a socketpair and you then receive an fd over that socket. What the helper does is really less important. Whether it's a script like you suggest or something like I proposed doesn't matter from a qemu perspective. 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 installation. You could even be clever in qemu and use call the helper using sudo if qemu is running as unpriviledged user and the helper is not a suid file. Arnd
Re: [Qemu-devel] [PATCH 4/4] Add support for -net bridge
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 devices can be created (and configured) in advance, and can be chowned so that they can be opened by an otherwise unprivileged user (or group). But that requires prior administrative access. You don't need root privileges to use a tap device. You can access a preconfigured tap device but you cannot allocate a tap device and connect it to a bridge without CAP_NET_ADMIN. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
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 installation. You could even be clever in qemu and use call the helper using sudo if qemu is running as unpriviledged user and the helper is not a suid file. Or just use fscaps and not even work about suid :-) That's the preferred model. Regards, Anthony Liguori
[Qemu-devel]question:arm's mutli-core emulator
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,
.use_scsi = 1,
+ .max_cpus = 2, -i change this
};
When i change the code,and exec qemu-system-arm -smp 2
It doesn't have the message Number of SMP cpus requested (2), exceeds max
cpus supported by machine `Versatile' (1)
I feel i am success,but i use the qemu shell and key info cpus to see the cpu
numbers
It only have one cpu,i am not success.
where is wrong?
thank you
Qun yi
