Re: [Qemu-devel] PATCH 0/8: Authentication support for the VNC server
These all look good to me! Regards, Anthony Liguori On Mon, 2007-08-13 at 20:25 +0100, Daniel P. Berrange wrote: > The current VNC server implementation does not have support for the > authentication of incoming client connections. The following series > of patches provide support for a number of alternatives, all compliant > with the VNC protocol spec. The simplest mechanism (and the weakest) > is the traditional VNC password scheme based on weak d3des hashing of > an 8 byte key. The more serious mechanism uses TLS for data encryption > of the entire session, and x509 certificates for both client and server > authentication. > > The patches are an iteration on the previous work I posted a couple > of weeks ago[1]. This addresses all the issues raised in the previous > review along with a couple of edge cases I discovered. Since TLS can be > quite perplexing, I also included some documentation on how to setup a > CA, and issue client & server certs in a manner suitable for use with > the VNC server. > > For the basic VNC password auth, this patch should be compatible with > any standard VNC client such as RealVNC. The TLS based auth schemes > require a client that implements the VeNCrypt extension[2]. The client > from the VeNCrypt[3] project of course is one example. The GTK-VNC[4] > widget which is used by Virt Manager[5] and Vinagre [6] also support > it, and are my primary testing platform. > > The 8 individual patches will follow shortly in replies to this mail. > > Regards, > Dan. > > [1] http://www.mail-archive.com/qemu-devel@nongnu.org/msg11554.html > [2] http://www.mail-archive.com/qemu-devel@nongnu.org/msg08681.html > [3] http://sourceforge.net/projects/vencrypt/ > [4] http://gtk-vnc.sourceforge.net/ > [5] http://virt-manager.org/ > [6] http://www.gnome.org/~jwendell/vinagre/
[Qemu-devel] qemu mips-dis.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/08/14 23:39:33 Modified files: . : mips-dis.c Log message: MIPS disassembler update. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/mips-dis.c?cvsroot=qemu&r1=1.5&r2=1.6
[Qemu-devel] Multimedia Demonstration of Building an RTEMS Toolchain, Application, and Running it in QEMU
Hello, In the process of writing my November 2006 article about RTEMS toolchain, I remembered that I recorded the whole process digitally so that I could go back and take notes. If you're interested in watching the presentation, it's available at: http://www.thoughtwave.com/ Just click on "Free UNIX Lessons" and then move your mouse cursor down to "Advanced" and select Building RTEMS toolchain. Or, you can go directly to http://www.thoughtwave.com/rtemsdemo.html Have fun, but make sure you have Flash installed and a good soundcard. Thanks, Jonathan -- -- Jonathan Kalbfeld +1 323 620 6682
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
yet colinux >= 0.7.1 is using I believe a similar approach for passing its parameters... quoting the readme: "colinux-daemon @example.conf" and this is what I use on a daily basis to compile detaolb on colinux (which I test later using qemu). On 8/14/07, Thiemo Seufer <[EMAIL PROTECTED]> wrote: > Jorge Lucángeli Obes wrote: > [snip] > > Quoting Thiemo, this '@' thing was "a feature which is now implemented > > in the GNU toolchain". That's why I tried it. Now I would like to know > > what he did to get it working. It would certainly be an useful > > feature, even if it does not exactly suit our purposes. > > Apparently I managed to create some misunderstanding. :-) > The @file feature was implemented in/for the _tools_ of the GNU > toolchain. It is not meant to become a general feature of all > linux userland applications. > > > Thiemo > > > -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Jorge Lucángeli Obes wrote: [snip] > Quoting Thiemo, this '@' thing was "a feature which is now implemented > in the GNU toolchain". That's why I tried it. Now I would like to know > what he did to get it working. It would certainly be an useful > feature, even if it does not exactly suit our purposes. Apparently I managed to create some misunderstanding. :-) The @file feature was implemented in/for the _tools_ of the GNU toolchain. It is not meant to become a general feature of all linux userland applications. Thiemo
Re: [Qemu-devel] adding support for above 2giga for qemu. ( include patchs )
On 8/14/07, Izik Eidus <[EMAIL PROTECTED]> wrote: > well, i used kind of older patch from you, > for to get it to work in pc, you have to change the cmos > and the vga page0, and page1 as well... > > anyway you have anyidea why it is working with kvm above 4giga and not > with qemu??? can you look at how i did the mapping in qemu? The patch looks OK, and my version just renamed some unsigned longs to host_phys_addr_t. There are probably more cases of incorrect use of uint32_t or int as address that need fixing in Qemu whereas kvm is cleaner in this sense.
[Qemu-devel] PATCH, RFC: Generic DMA framework
Hi,
The first patch implements a simple generic DMA framework. The next
patches convert first Sparc32 IOMMU and then ESP and Lance.
Would the framework need any changes to support other targets? Comments welcome.
Index: qemu/vl.h
===
--- qemu.orig/vl.h 2007-08-14 19:25:52.0 +
+++ qemu/vl.h 2007-08-14 19:26:34.0 +
@@ -734,6 +734,50 @@
#include "hw/irq.h"
+/* Generic DMA API */
+typedef void (*qemu_dma_handler)(void *opaque, target_phys_addr_t addr,
+ uint8_t *buf, int len, int is_write);
+
+typedef struct QEMUDMAState {
+qemu_dma_handler handler;
+void *opaque;
+} qemu_dma;
+
+static inline void dma_memory_read(qemu_dma *dma_opaque,
+ target_phys_addr_t addr,
+ uint8_t *buf, int len)
+{
+if (dma_opaque)
+dma_opaque->handler(dma_opaque->opaque, addr, buf, len, 0);
+}
+
+static inline void dma_memory_write(qemu_dma *dma_opaque,
+target_phys_addr_t addr,
+uint8_t *buf, int len)
+{
+if (dma_opaque)
+dma_opaque->handler(dma_opaque->opaque, addr, buf, len, 1);
+}
+
+static inline void dma_memory_rw(qemu_dma *dma_opaque,
+ target_phys_addr_t addr,
+ uint8_t *buf, int len, int is_write)
+{
+if (dma_opaque)
+dma_opaque->handler(dma_opaque->opaque, addr, buf, len, is_write);
+}
+
+static inline qemu_dma *qemu_init_dma(qemu_dma_handler handler, void *opaque)
+{
+qemu_dma *s;
+
+s = (qemu_dma *)qemu_mallocz(sizeof(qemu_dma));
+s->handler = handler;
+s->opaque = opaque;
+
+return s;
+}
+
/* ISA bus */
extern target_phys_addr_t isa_mem_base;
Index: qemu/hw/sun4m.c
===
--- qemu.orig/hw/sun4m.c 2007-08-14 19:26:56.0 +
+++ qemu/hw/sun4m.c 2007-08-14 19:37:20.0 +
@@ -289,6 +289,12 @@
slavio_set_power_fail(slavio_misc, 1);
}
+static void sparc_dma_memory_rw(void *opaque, target_phys_addr_t addr,
+uint8_t *buf, int len, int is_write)
+{
+cpu_physical_memory_rw(addr, buf, len, is_write);
+}
+
static void main_cpu_reset(void *opaque)
{
CPUState *env = opaque;
@@ -315,6 +321,7 @@
const sparc_def_t *def;
qemu_irq *cpu_irqs[MAX_CPUS], *slavio_irq, *slavio_cpu_irq,
*espdma_irq, *ledma_irq;
+qemu_dma *physical_dma, *dvma;
/* init CPUs */
sparc_find_by_name(cpu_model, &def);
@@ -343,7 +350,10 @@
/* allocate RAM */
cpu_register_physical_memory(0, RAM_size, 0);
-iommu = iommu_init(hwdef->iommu_base);
+physical_dma = qemu_init_dma(sparc_dma_memory_rw, NULL);
+
+iommu = iommu_init(hwdef->iommu_base, physical_dma, &dvma);
+
slavio_intctl = slavio_intctl_init(hwdef->intctl_base,
hwdef->intctl_base + 0x1ULL,
&hwdef->intbit_to_level[0],
Index: qemu/hw/iommu.c
===
--- qemu.orig/hw/iommu.c 2007-08-14 19:27:35.0 +
+++ qemu/hw/iommu.c 2007-08-14 19:36:33.0 +
@@ -104,6 +104,7 @@
target_phys_addr_t addr;
uint32_t regs[IOMMU_NREGS];
target_phys_addr_t iostart;
+qemu_dma *parent_dma;
} IOMMUState;
static uint32_t iommu_mem_readw(void *opaque, target_phys_addr_t addr)
@@ -245,6 +246,7 @@
void sparc_iommu_memory_rw(void *opaque, target_phys_addr_t addr,
uint8_t *buf, int len, int is_write)
{
+IOMMUState *s = opaque;
int l;
uint32_t flags;
target_phys_addr_t page, phys_addr;
@@ -265,10 +267,8 @@
iommu_bad_addr(opaque, page, is_write);
return;
}
-cpu_physical_memory_write(phys_addr, buf, len);
-} else {
-cpu_physical_memory_read(phys_addr, buf, len);
}
+dma_memory_rw(s->parent_dma, phys_addr, buf, len, is_write);
len -= l;
buf += l;
addr += l;
@@ -309,7 +309,8 @@
s->regs[IOMMU_CTRL] = IOMMU_VERSION;
}
-void *iommu_init(target_phys_addr_t addr)
+void *iommu_init(target_phys_addr_t addr, qemu_dma *parent_dma,
+ qemu_dma **dvma)
{
IOMMUState *s;
int iommu_io_memory;
@@ -322,7 +323,10 @@
iommu_io_memory = cpu_register_io_memory(0, iommu_mem_read, iommu_mem_write, s);
cpu_register_physical_memory(addr, IOMMU_NREGS * 4, iommu_io_memory);
-
+
+s->parent_dma = parent_dma;
+*dvma = qemu_init_dma(sparc_iommu_memory_rw, s);
+
register_savevm("iommu", addr, 2, iommu_save, iommu_load, s);
qemu_register_reset(iommu_reset, s);
return s;
Index: qemu/vl.h
===
--- qemu.orig/vl.h 2007-08
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
On 8/14/07, Laurent Vivier <[EMAIL PROTECTED]> wrote: > Markus Hitter wrote: > > > > Am 13.08.2007 um 11:19 schrieb Laurent Vivier: > > > >> We can modify qemu to test if the argument is a directory, if yes, it > >> reads args > >> from file args in this directory and for security the disk image must > >> be in the > >> same directory. > >> > >> for instance, we have: > >> > >> ./pc1/ > >> ./pc1/args > >> ./pc1/my_disk > >> > >> and in ./pc1/args, we have "-hda my_disk" > > > > ... and "-hdb ../pc2/my_other_disk" > > If we want to preserve security we should forbid this, but you can make a > soft link: > > ln -s shared_disks/my_disk1 pc1/my_shared_disk > ln -s shared_disks/my_disk1 pc2/my_shared_disk > > and have pc1/args and pc2/args = "-hda my_disk -hdb my_shared_disk" > to have: > > qemu -hda pc1/my_disk -hdb pc1/my_shared_disk > > qemu -hda pc2/my_disk and -hdb pc2/my_shared_disk > > > The directory idea sounds good. Especially for me, as I'm obviously the > > only one running one disk image in different virtual machines. > > > > Plus, it'd work for physical partitions / disks: Simply have a directory > > with an "args" file only. > > > > > > my $ 0.01 > > Markus Quoting Thiemo, this '@' thing was "a feature which is now implemented in the GNU toolchain". That's why I tried it. Now I would like to know what he did to get it working. It would certainly be an useful feature, even if it does not exactly suit our purposes. I still think that the executable-image approach could work nicely. However, the point in favour of a configuration directory when using physical partitions or disks is good. Nonetheless, a physical partition is much less "volatile" than an disk image, so the disadvantage of keeping a shell script is small in that case. Cheers, Jorge
Re: [Qemu-devel] adding support for above 2giga for qemu. ( include patchs )
well, i used kind of older patch from you, for to get it to work in pc, you have to change the cmos and the vga page0, and page1 as well... anyway you have anyidea why it is working with kvm above 4giga and not with qemu??? can you look at how i did the mapping in qemu?
Re: [Qemu-devel] adding support for above 2giga for qemu. ( include patchs )
On 8/14/07, Izik Eidus <[EMAIL PROTECTED]> wrote:
> hey,
> i have wrote a patch to qemu to allow it to run with above the 2giga
> limitations we have now.
> i tested it on qemu that used kvm with 14giga of ram, and it was tested at
> other place with 32giga of ram to the guest ( 32bits, and 64bits).
Great! So it does work on x86, on Sparc there were problems.
I updated my patch by introducing a host_phys_addr_t type. There were
a long discussion about host address type, I think the result was that
'unsigned long' works as it ever has except for Win64.
I don't know which is better strategy, do int to unsigned long
conversion first (like your patch) and then replace unsigned long with
host_phys_addr_t, or vice versa. Or direct int -> host_phys_addr_t
which this patch does.
Index: qemu/exec.c
===
--- qemu.orig/exec.c 2007-07-03 09:53:41.0 +
+++ qemu/exec.c 2007-08-14 14:33:39.0 +
@@ -86,7 +86,7 @@
uint8_t code_gen_buffer[CODE_GEN_BUFFER_SIZE] __attribute__((aligned (32)));
uint8_t *code_gen_ptr;
-int phys_ram_size;
+host_phys_addr_t phys_ram_size;
int phys_ram_fd;
uint8_t *phys_ram_base;
uint8_t *phys_ram_dirty;
@@ -111,7 +111,7 @@
typedef struct PhysPageDesc {
/* offset in host memory of the page + io_index in the low 12 bits */
-uint32_t phys_offset;
+host_phys_addr_t phys_offset;
} PhysPageDesc;
#define L2_BITS 10
@@ -1925,7 +1925,7 @@
static int subpage_register (subpage_t *mmio, uint32_t start, uint32_t end,
int memory);
-static void *subpage_init (target_phys_addr_t base, uint32_t *phys,
+static void *subpage_init (target_phys_addr_t base, host_phys_addr_t *phys,
int orig_memory);
#define CHECK_SUBPAGE(addr, start_addr, start_addr2, end_addr, end_addr2, \
need_subpage) \
@@ -2033,8 +2033,8 @@
{
ram_addr_t addr;
if ((phys_ram_alloc_offset + size) >= phys_ram_size) {
-fprintf(stderr, "Not enough memory (requested_size = %u, max memory = %d)\n",
-size, phys_ram_size);
+fprintf(stderr, "Not enough memory (requested_size = %u, max memory = "
+HOST_FMT_pld ")\n", size, phys_ram_size);
abort();
}
addr = phys_ram_alloc_offset;
@@ -2369,7 +2369,7 @@
return 0;
}
-static void *subpage_init (target_phys_addr_t base, uint32_t *phys,
+static void *subpage_init (target_phys_addr_t base, host_phys_addr_t *phys,
int orig_memory)
{
subpage_t *mmio;
Index: qemu/vl.c
===
--- qemu.orig/vl.c 2007-08-11 12:18:40.0 +
+++ qemu/vl.c 2007-08-14 14:35:06.0 +
@@ -116,7 +116,11 @@
//#define DEBUG_UNUSED_IOPORT
//#define DEBUG_IOPORT
+#if HOST_LONG_BITS < 64
#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024)
+#else
+#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024 * 1024ULL)
+#endif
#ifdef TARGET_PPC
#define DEFAULT_RAM_SIZE 144
@@ -151,7 +155,7 @@
const char* keyboard_layout = NULL;
int64_t ticks_per_sec;
int boot_device = 'c';
-int ram_size;
+host_phys_addr_t ram_size;
int pit_min_timer_count = 0;
int nb_nics;
NICInfo nd_table[MAX_NICS];
@@ -7472,12 +7476,13 @@
help(0);
break;
case QEMU_OPTION_m:
-ram_size = atoi(optarg) * 1024 * 1024;
+ram_size = (host_phys_addr_t)atoi(optarg) * 1024 * 1024;
if (ram_size <= 0)
help(1);
if (ram_size > PHYS_RAM_MAX_SIZE) {
-fprintf(stderr, "qemu: at most %d MB RAM can be simulated\n",
-PHYS_RAM_MAX_SIZE / (1024 * 1024));
+fprintf(stderr, "qemu: at most " HOST_FMT_pld
+" MB RAM can be simulated\n",
+(host_phys_addr_t)PHYS_RAM_MAX_SIZE / (1024 * 1024));
exit(1);
}
break;
Index: qemu/vl.h
===
--- qemu.orig/vl.h 2007-08-14 14:31:46.0 +
+++ qemu/vl.h 2007-08-14 14:33:39.0 +
@@ -145,7 +145,9 @@
void main_loop_wait(int timeout);
-extern int ram_size;
+#ifndef QEMU_TOOL
+extern host_phys_addr_t ram_size;
+#endif
extern int bios_size;
extern int rtc_utc;
extern int cirrus_vga_enabled;
@@ -707,7 +709,7 @@
#ifndef QEMU_TOOL
-typedef void QEMUMachineInitFunc(int ram_size, int vga_ram_size,
+typedef void QEMUMachineInitFunc(host_phys_addr_t ram_size, int vga_ram_size,
int boot_device,
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
@@ -942,24 +944,24 @@
}
int isa_vga_init(DisplayState *ds, uint8_t *vga_ram_base,
-
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Markus Hitter wrote: > > Am 13.08.2007 um 11:19 schrieb Laurent Vivier: > >> We can modify qemu to test if the argument is a directory, if yes, it >> reads args >> from file args in this directory and for security the disk image must >> be in the >> same directory. >> >> for instance, we have: >> >> ./pc1/ >> ./pc1/args >> ./pc1/my_disk >> >> and in ./pc1/args, we have "-hda my_disk" > > ... and "-hdb ../pc2/my_other_disk" If we want to preserve security we should forbid this, but you can make a soft link: ln -s shared_disks/my_disk1 pc1/my_shared_disk ln -s shared_disks/my_disk1 pc2/my_shared_disk and have pc1/args and pc2/args = "-hda my_disk -hdb my_shared_disk" to have: qemu -hda pc1/my_disk -hdb pc1/my_shared_disk qemu -hda pc2/my_disk and -hdb pc2/my_shared_disk > The directory idea sounds good. Especially for me, as I'm obviously the > only one running one disk image in different virtual machines. > > Plus, it'd work for physical partitions / disks: Simply have a directory > with an "args" file only. > > > my $ 0.01 > Markus > > - - - - - - - - - - - - - - - - - - - > Dipl. Ing. Markus Hitter > http://www.jump-ing.de/ > > > > > > > -- - [EMAIL PROTECTED] -- "Software is hard" - Donald Knuth signature.asc Description: OpenPGP digital signature
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
On 14 Aug 2007, at 00:31, Thiemo Seufer wrote: Philip Boulain wrote: On 13 Aug 2007, at 20:39, Thiemo Seufer wrote: ...implemented in the GNU toolchain, and apparently stems from Windows: qemu @qemu.cfg I'm not familiar with that. Is it just GNU bash shorthand for qemu `cat qemu.cfg` ? I don't think it has anything to do with bash. Apparently Windows(NT) cmd.exe introduced this as a way to avoid unwieldy command lines. Cygwin (or MingGW?) added the same to their tools in order to avoid command line length problems. Not so long ago it was implemented for gcc and binutils... Ugh. This is in-application magic that does a pre-parsing step on argv []? I'm suddenly being flooded with horrible memories of how Win-DOS requires each individual application to implement its own wildcards in arguments, and how these implementations were inevitably inconsistent in ways that stabbed you in the face. Maybe QEMU /should/ have a "...and read this file as arguments..." argument, but this really doesn't seem a good way to do it. "-c qemu.cfg" is a lot less ambiguous, as you don't have to worry about whether an '@' in an argument is an include command, or a literal, e.g. part of a filename (it could be either, and escaping it at the shell level won't help). LionsPhil
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Am 13.08.2007 um 11:19 schrieb Laurent Vivier: We can modify qemu to test if the argument is a directory, if yes, it reads args from file args in this directory and for security the disk image must be in the same directory. for instance, we have: ./pc1/ ./pc1/args ./pc1/my_disk and in ./pc1/args, we have "-hda my_disk" ... and "-hdb ../pc2/my_other_disk" The directory idea sounds good. Especially for me, as I'm obviously the only one running one disk image in different virtual machines. Plus, it'd work for physical partitions / disks: Simply have a directory with an "args" file only. my $ 0.01 Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
[Qemu-devel] adding support for above 2giga for qemu. ( include patchs )
hey, i have wrote a patch to qemu to allow it to run with above the 2giga limitations we have now. i tested it on qemu that used kvm with 14giga of ram, and it was tested at other place with 32giga of ram to the guest ( 32bits, and 64bits). the patch that i send here, is patch to qemu without kvm, it include patch to the bochs bios, and patch to the qemu. part of the patch to qemu fix the typedefs varibles to unsigned long, and it is based on patch i saw at this list that target sparc. for some reason the mapping that i do inside qemu with cpu_register_physical_memory dont work, and with this patchs qemu could not work with more than 3.75giga of ram. ( with kvm it does working... ) this is request for comment, i probbley doing something wrong inside qemu, so anyone have idea how to solve it please comment :) anyway for to make it easy to run i put here compiled patched bios. have fun! :-) bochs_bios_ram_patch Description: bochs_bios_ram_patch qemu_ram_patch Description: qemu_ram_patch
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Thiemo Seufer wrote: > Jorge Lucángeli Obes wrote: > [snip] >> When I read Avi's TODO, I basically thought about getting rid of the >> long command lines I had to store in scripts. I wanted to write that >> command line once, and then forgetting about it, until I needed to >> change it. > > Instead of inventing great and wonderfully complicated schemes, the > most sensible way I can think of is to recycle a feature which is now > implemented in the GNU toolchain, and apparently stems from Windows: > > qemu @qemu.cfg > > where qemu.cfg is a file which contains the command line arguments. > (This is also low-maintenance, as it allows to re-use the existing IMHO, it should be implemented at the shell level, not qemu level, like "*" is. Laurent -- - [EMAIL PROTECTED] -- "Software is hard" - Donald Knuth signature.asc Description: OpenPGP digital signature
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Jorge Lucángeli Obes schrieb: > qemu: could not open hard disk image '@config' I think this was a suggestion for implementation, not a working feature. > I did not know about '@config', and if I can get it to work, I like it > better than a shell script. However, I think it does not completely > solve the problem. It still means two files per VM. As long as it is not possible to store more than one image in one file, this problem won't be solved completely anyway. Kevin
