Stefano Stabellini writes ("[Xen-devel] [PATCH 0/2] QEMU/xen: simplify
cpu_ioreq_pio and cpu_ioreq_move"):
> after reviewing the patch "fix multiply issue for int and uint types"
> with Ian Jackson, we realized that cpu_ioreq_pio and cpu_ioreq_move are
> in much need
Ian Campbell writes ("Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simplify
cpu_ioreq_pio and cpu_ioreq_move"):
> On Fri, 2012-12-07 at 16:14 +, Ian Jackson wrote:
> > +target_phys_addr_t offset = (target_phys_addr_t)req->size * i;
> > +if (req->df) add
Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simplify
cpu_ioreq_pio and cpu_ioreq_move"):
> On Fri, 7 Dec 2012, Ian Jackson wrote:
...
> > +if (req->df) addr -= offset;
> > +else addr -= offset;
>
> This can't be right, can it?
These two patches fix a potential infinite loop if an ioreq has a very
large count, and also simplifies the code.
Replace a lot of formulaic multiplications (containing casts, no less)
with calls to a pair of functions. This encapsulates in a single
place the operations which require care relating to integer overflow.
Cc: Dongxiao Xu
Cc: Stefano Stabellini
Signed-off-by: Ian Jackson
---
xen-all.c | 73
Signed-off-by: Ian Jackson
---
xen-all.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen-all.c b/xen-all.c
index 97c8ef4..aabbb80 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -717,7 +717,7 @@ static inline void write_phys_req_item(hwaddr addr,
static void cpu_ior
Pasi Kärkkäinen writes ("Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simplify
cpu_ioreq_pio and cpu_ioreq_move / Xen on Xen nested virt"):
> Ping again? I wonder if I've gotten into some blacklist already for nagging
> about this..
>
> This is a required patch for making Xen-on-Xen Nested virt work
Chunyan Liu writes ("[RFC PATCH V3 1/2] xen: pass kernel initrd to qemu"):
> xen side patch to support xen HVM direct kernel boot:
> support 'kernel', 'ramdisk', 'cmdline' (and 'root', 'extra' as well
> which would be deprecated later) in HVM config file, parse config file,
> pass -kernel, -initrd,
Wei Wang writes ("Re: [Xen-devel] [PATCH 1 of 6 V6] amd iommu: Add 2 hypercalls
for libxc"):
> Well, the hypercall itself is very simple and straightforward. It just
> allow qemu to notify Xen guest iommu msi configurations. Except this,
> there is also a need in qemu of registering a virtual io
Stefano Stabellini writes ("Re: [Xen-devel] [PATCH, v3] qemu/xendisk: set
maximum number of grants to be used"):
> On Thu, 31 May 2012, Jan Beulich wrote:
> > > It should be applied to qemu-xen-traditional too.
> >
> > And the other one ("qemu/xendisk: properly update stats in
> > ioreq_release()
Julien Grall writes ("[Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse the
new option device_models"):
> For the support of multiple ioreq server, we add a new option "device_models".
> It's an array of device model, for each device model, we need to specify
> which pci, IO range (MMIO, PIO) w
Julien Grall writes ("[Xen-devel] [XEN][RFC PATCH 01/15] hvm: Modify interface
to support multiple ioreq server"):
> Add structure to handle ioreq server. It's server which can
> handle a range of IO (MMIO and/or PIO) and emulate a PCI.
> Each server as its own shared page to receive ioreq. So
> w
Stefano Stabellini writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing:
Parse the new option device_models"):
> On Mon, 2 Apr 2012, Ian Jackson wrote:
> > I don't think this is really a suitable interface. The PCI space in
> > the guest is controlled by the
Julien Grall writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing: Parse
the new option device_models"):
> On 04/03/2012 02:31 PM, Ian Jackson wrote:
> > Are the PCI addresses not assigned in a deterministic fashion by code
> > in qemu-dm, in this case in the qemu-
Stefano Stabellini writes ("Re: [Xen-devel] [XEN][RFC PATCH 14/15] xl-parsing:
Parse the new option device_models"):
> On Tue, 3 Apr 2012, Ian Jackson wrote:
> > Currently the bdfs are allocated by the single qemu-dm, right ? Why
> > cannot that functionality stay t
Olaf Hering writes ("[Xen-devel] [PATCH v2] qemu/configure: fix CFLAGS handling
for i386"):
> configure will generate incorrect CFLAGS which will lead to compile
> errors due to unknown gcc options, iff CFLAGS was already in the
> environment during configure invocation.
Don't do that then.
In g
Alexander Graf writes ("[Xen-devel] Re: [PATCH 1/4] xen: Clean up build
system"):
> On 21.06.2011, at 08:26, Jan Kiszka wrote:
> > From: Jan Kiszka
> >
> > Introduce CONFIG_XEN_BACKEND so that this new config solely controls the
> > target-independent backend build and CONFIG_XEN can focus on pe
Anthony PERARD writes ("[Xen-devel] [PATCH V3 10/13] libxl: libxl_qmp:
Introduce libxl__qmp_pci_add."):
> This function insert a PCI passthrough device in qemu.
Thanks. I have applied 1-9 from this series. 13/13 had a conflict,
and I wasn't 100% sure that it was right to apply it without 10,11,
Anthony PERARD writes ("[Xen-devel] [PATCH V3 11/13] libxl: Use QMP to insert a
passthrough device when using upstream QEMU"):
> Also move the xenstore specific code to a new function and add a
> message if sscanf fails.
Thanks, following discussion I've applied 10,11 and will wait with 12
for th
Chen, Tiejun writes ("Re: [Qemu-devel] [RFC][PATCH 1/1] libxl: add one machine
property to support IGD GFX passthrough"):
> On 2015/1/23 8:43, Chen, Tiejun wrote:
> > On 2015/1/22 8:51, Chen, Tiejun wrote:
> >> At this point I just concern here if we still use 'gfx_passthrou', at
> >> least it may
Wei Liu writes ("Re: [v2][PATCH] libxl: add one machine property to support IGD
GFX passthrough"):
> On Mon, Feb 02, 2015 at 09:17:23AM +0800, Tiejun Chen wrote:
> > When we're working to support IGD GFX passthrough with qemu
> > upstream, instead of "-gfx_passthru" we'd like to make that
> > a ma
Tiejun Chen writes ("[RFC][PATCH 1/1] libxl: add one machine property to
support IGD GFX passthrough"):
> When we're working to support IGD GFX passthrough with qemu
> upstream, instead of "-gfx_passthru" we'd like to make that
> a machine option, "-machine xxx,gfx_passthru=on". This need
> to bri
Fabio Fantoni writes ("Re: [PATCH v3] libxl: usb2 and usb3 controller support
for upstream qemu"):
> Il 12/07/2013 17:33, George Dunlap ha scritto:
> > On 12/07/13 13:36, Fabio Fantoni wrote:
[someone wrote:]
> >>> I'm just curious, why is this so complicated? Is this likely to be
> >>> fragile
Anthony Liguori writes ("Re: [Qemu-devel] [PATCH v3] libxl: usb2 and usb3
controller support for upstream qemu"):
> The current way of creating each function will always be supported though.
Thanks for that reply. I'm reassured.
Ian.
Alex Bligh writes ("Re: [Qemu-devel] [PATCH v2] xen_disk: support
"direct-io-safe" backend option"):
> Stefano,
> --On 27 June 2013 19:16:30 +0100 Stefano Stabellini
> wrote:
>
> > * Therefore this option gives the backend permission to use
> > * O_DIRECT, notwithstanding that
Paolo Bonzini writes ("Re: [PATCH v2] xen_disk: support "direct-io-safe"
backend option"):
> Il 27/06/2013 20:16, Stefano Stabellini ha scritto:
> > The original proposal for a "cache" backend option has been dropped
> > because it was believed too wide, especially considering that at the
> > mome
Wei Wang2 writes ("[Xen-devel] [PATCH] xen-qemu: register virtual iommu device
on qemu pci bus"):
> Attached patch is for qemu to register iommu device on pci bus. Guest OS
> requires this to access iommu pci config space in some cases.
Thanks for this submission.
However, we are trying to focu
Ian Campbell writes ("Re: [RFC PATCH V3 1/2] xen: pass kernel initrd to qemu"):
> On Mon, 2014-06-23 at 15:22 +0100, Ian Jackson wrote:
> > If we are going to do this then I think the kernel, cmdline and
> > ramdisk (and bootloader) parameters shoudl be moved into
Stefano Stabellini writes ("Re: [PATCH v2] libxl: change default QEMU machine
to pc-i440fx-1.6"):
> ping?
>
> On Thu, 12 Jun 2014, Stefano Stabellini wrote:
...
> > This patch does not change the emulated environment in the guest, unless
> > soundhw='hda' is specified, in that case the xen-platfo
Christoph Hellwig writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH] qemu and
qemu-xen: support empty write barriers in xen_disk"):
> On Wed, Nov 24, 2010 at 10:18:40AM -0800, Jeremy Fitzhardinge wrote:
> > Linux wants is a useful thing to do and implement (especially since it
> > amounts to standa
Gerd Hoffmann writes ("[Xen-devel] Re: [Qemu-devel] [PATCH] qemu and qemu-xen:
support empty write barriers in xen_disk"):
> On 11/24/10 14:08, Stefano Stabellini wrote:
> > this patch can be applied to both qemu-xen and qemu and adds support
> > for empty write barriers to xen_disk.
>
> Looks go
Gerd Hoffmann writes ("Re: [PATCH] add event queueing to USB HID"):
> On 12/23/10 15:57, Paolo Bonzini wrote:
> > @@ -68,7 +77,7 @@ typedef struct USBHIDState {
> > int protocol;
> > uint8_t idle;
> > int64_t next_idle_clock;
> > -int changed;
> > +int have_data, changed;
I wrote:
> Paulo: For reference, here is a diff of the relevant functionality.
> It's against qemu 0.10.0 (ish) but it may be a better starting point
> than what you used.
I just had a go at seeing how that applies to current upstream master
and it doesn't look like it would be hard to fix up.
Ia
Paolo Bonzini writes ("[PATCH v2] add event queueing to USB HID"):
> For v2 I changed the head/tail implementation of the FIFO buffer
> (which was buggy when the queue became full) to head/count.
> I then removed "have_data", which is the same as count>0
> for pointe
my version of the code.
Hrm.
> 2) if buffering is implemented for the keyboard device (and it probably
> should) most of the differences would go away again.
True.
> 3) Secondarily, this is the only part of your patch that would need
> adjustments, since finite idle delays are now implemented.
Right.
OK. Thanks for your work.
Acked-by: Ian Jackson
Ian.
Stefano Stabellini writes ("[Xen-devel] [PATCH 2/5] qemu and qemu-xen: fix
segfault on con_disconnect"):
> The test on xendev->gnttabdev in con_disconnect is wrong: what
> differentiates the consoles is the dev number.
Thanks, I have applied this patch to qemu-xen-unstable.git.
Ian.
Blue Swirl writes ("[Xen-devel] Re: [Qemu-devel] [PATCH 03/15] xen: Add a new
target to qemu: target-xen"):
> I don't understand why it would be a target, QEMU calls CPU
> architectures targets. Isn't it possible to have Xen for Sparc, PPC or
> ARM? It should really be just a machine, not copy&pas
andrzej zaborowski writes ("Re: [Qemu-devel] [PATCH] ioemu/qemu vga: save and
restore vram buffer (revised)"):
> On a second look there's something else I don't understand. The vram
> window is in RAM in stdvga, it's inside phys_ram_base, and the entire
> chunk pointed to by phys_ram_base is saved
Paul Brook writes ("Re: [Qemu-devel] [PATCH] ioemu/qemu vga: save and
> restore vram buffer (revised)"): If you look closer, you'll find
> that s->vram_ptr actually points to an offset from phys_ram_base. So
> the VGA framebuffer is already saved by ram_save.
Oh yes. That's not the case in the Xe
andrzej zaborowski writes ("Re: [Qemu-devel] xen / qemu convergence ?"):
> There's currently no way in qemu to map a chunk of host memory to
> guest memory 1:1 if it's not in phys_ram_base, so all video adapters
> in qemu do that. Mapped memory that's part of phys_ram_base also gets
> dirty pages t
qemu's audio subdirectory contains a copy of BSD's sys-queue.h, which
defines a bunch of LIST_ macros. This makes it difficult to build a
program made partly out of qemu and partly out of the Linux kernel[1],
since Linux has a different set of LIST_ macros. It might also cause
trouble when mixing
Paul Brook writes ("Re: [Qemu-devel] [PATCH] CPPFLAGS+= in Makefile.target"):
> Huh? No it doesn't. config-host.mak contains
> CPPFLAGS=
> then Makefile.target contains
> CPPFLAGS+=whatever
It doesn't seem to on my build.
> Why don't you just put your custom flags in CFLAGS, not CPPFLAGS?
> The f
Johannes Schindelin writes ("Re: [Qemu-devel] [PATCH] Allow AF_UNIX sockets to
be disabled on non-Windows"):
> Yes, that is very ugly. But changing it to
> #ifndef NO_AF_UNIX_SOCKETS
> it actually gives you a bit of documentation what the code does, in
> addition to controlling what is compile
Paul Brook writes ("Re: [Qemu-devel] [PATCH] CPPFLAGS+= in Makefile.target"):
> Really? Which ones?
tests/Makefile and tests/cris/Makefile do. Not that they're
particularly important. I also saw Makefile.target's if'd out change
to CFLAGS near at the bottom by the audio .o's, but of course that'
qemu-img.c has copies of qemu_malloc et al, which are already provided
in osdep.c. The attached patch removes these from qemu-img.c and
adds osdep.o to BLOCK_OBJS.
(It wants to be in BLOCK_OBJS rather than just in qemu-img to support
my next patch.)
Regards,
Ian.
Index: Makefile
===
The system calls read and write may return less than the whole amount
requested for a number of reasons. So the idioms
if (read(fd, &object, sizeof(object)) != sizeof(object)) goto fail;
and even worse
if (read(fd, &object, sizeof(object)) < 0) goto fail;
are wrong. Additionally, read and w
Saying CPPFLAGS+= is much more convenient if for any reason the
external build environment would like to pass unusual CPPFLAGS.
Regards,
Ian.
Index: Makefile.target
===
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving revisi
Paul Brook writes ("Re: [Qemu-devel] [PATCH] CPPFLAGS+= in Makefile.target"):
> No. This doesn't do what you thing it does.
> The most common way of overriding these variables is to pass them on the
> commandline, i.e. "make CPPFLAGS=-blah". This overrides all assignments to
> that variable inclu
iwj writes ("Re: [Qemu-devel] [PATCH] CPPFLAGS+= in Makefile.target"):
> Paul Brook writes ("Re: [Qemu-devel] [PATCH] CPPFLAGS+= in Makefile.target"):
> > No. This doesn't do what you thing it does.
> > The most common way of overriding these variables is to pass them on the
> > commandline, i.e.
The patch below makes it possible to disable AF_UNIX (unix-domain)
sockets in host environments which do not define _WIN32, by adding
-DNO_UNIX_SOCKETS to the compiler flags. This is useful in the
effectively-embedded qemu host which are going to be using for device
emulation in Xen.
Ian.
Index:
Anthony Liguori writes ("Re: [Qemu-devel] [PATCH] Allow AF_UNIX sockets to be
disabled on non-Windows"):
> Presumably, this is because you're compiling for MiniOS? Why not just
> add a _MINIOS define and then add an appropriate #ifndef.
Yes. We'll probably add a MINIOS define, yes (at the mome
Paul Brook writes ("Re: [Qemu-devel] [PATCH] CPPFLAGS+= in Makefile.target"):
> On Friday 25 January 2008, Ian Jackson wrote:
> > What circumstances ? CPPFLAGS+= overrides (discards) values in the
> > environment as well as ones from the command line.
>
> [ demonst
Paul Brook writes ("Re: [Qemu-devel] [PATCH] CPPFLAGS+= in Makefile.target"):
> In that case you should always provide a definition in config-host.mak.
> Under some circumstances make may inherit initial values from elsewhere.
What circumstances ? CPPFLAGS+= overrides (discards) values in the
env
Anthony Liguori writes ("[Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use correct
types to enable > 2G support"):
> The alternative is to change all the places that assume phys_ram_base +
> PA which I don't like very much.
We would ideally like to do this for Xen, at least in the places we
care abou
Fabrice Bellard writes ("[Qemu-devel] Re: [PATCH 1/6] Use correct types to
enable > 2G support"):
> Paul Brook wrote: If we ever implement >2G ram on a 32-bit host this
> > may need some rethinking. We can deal with that if/when it
> > happens though. Requiring a 64-bit host for large quantities
Andreas Schwab writes ("Re: [Qemu-devel] Making qemu use 10.0.3.x not
10.0.2.x"):
> Samuel Thibault <[EMAIL PROTECTED]> writes:
> > Mmm, actually, shouldn't qemu use a more "private" network like a
> > RFC1918 172.16.0.0/12 network?
>
> In which way is 172.16.0.0/12 more "private" than 10.0.0.0/8
Warner Losh writes ("Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x"):
> I think that the suggestion is that qemu picks, one time, a new
> default. This new default would be selected at random, and would be
> the same on all new versions of qemu.
Yes.
> I don't think that the suggestion
iwj writes ("[PATCH] avoid name clashes due to LIST_* macros"):
> qemu's audio subdirectory contains a copy of BSD's sys-queue.h, which
> defines a bunch of LIST_ macros. This makes it difficult to build a
> program made partly out of qemu and partly out of the Linux kernel[1],
> since Linux has a
andrzej zaborowski writes ("Re: [Qemu-devel] Making qemu use 10.0.3.x not
10.0.2.x"):
> Right, but this happens so rarely (and there are no obvious symptoms
> when it happens)
The symptoms are generally that the host loses its network connection
to those parts of the outside world, or that it can
iwj writes ("[PATCH] Remove clone-and-hack code from qemu-img"):
> qemu-img.c has copies of qemu_malloc et al, which are already provided
> in osdep.c. The attached patch removes these from qemu-img.c and
> adds osdep.o to BLOCK_OBJS.
Is there some reason why this patch has not yet been included
iwj writes ("[PATCH] Allow AF_UNIX sockets to be disabled on non-Windows"):
> The patch below makes it possible to disable AF_UNIX (unix-domain)
> sockets in host environments which do not define _WIN32, by adding
> -DNO_UNIX_SOCKETS to the compiler flags. This is useful in the
> effectively-embed
iwj writes ("[PATCH] check return value from read() and write() properly"):
> The system calls read and write may return less than the whole amount
> requested for a number of reasons. So the idioms
>if (read(fd, &object, sizeof(object)) != sizeof(object)) goto fail;
> and even worse
>if (
Anthony Liguori writes ("Re: [Qemu-devel] [PATCH] avoid name clashes due to
LIST_* macros"):
> Ian Jackson wrote:
> > qemu's audio subdirectory contains a copy of BSD's sys-queue.h, which
> > defines a bunch of LIST_ macros. This makes it difficult to build a
Anthony Liguori writes ("Re: [Qemu-devel] [PATCH] check return value from
read() and write() properly"):
> Ian Jackson wrote:
> > The system calls read and write may return less than the whole amount
> > requested for a number of reasons. So the idioms
> >if (
Johannes Schindelin writes ("Re: [Qemu-devel] [PATCH] avoid name clashes due to
LIST_* macros"):
> Read what you wrote. By that reasoning you cannot use _any_ name in qemu,
> because qemu should bend over to be mixable with other code.
No, not at all. Just that when a clash happens something s
Johannes Schindelin writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> Now, that is funny. You quote me, and you quote Rob, but culled both of
> us from the Cc list.
How strange. I definitely didn't mean to do that, sorry.
...tests...
This is the fault of the Reply-To munging.
Ia
Rob Landley writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> Any news on the possible cvs->svn migration?
To be perfectly honest, IMO there is little point moving an existing
project from CVS to SVN. SVN has better support for renames, and a
few other advantages, but branching is st
Johannes Schindelin writes ("Re: Git/SVN/CVS? was Re: [Qemu-devel] What does
code_copy_enabled do?"):
> Just clone git://repo.or.cz/qemu.git, then.
Rob Landley writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> ... the git mirror I follow (git://git.kernel.dk/data/git/qemu.git) ...
I
Johannes Schindelin writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> If you mean the one at repo.or.cz and the one at kernel.dk, no. They
> contain exactly the same history.
You're right. I hadn't checked. My own mirror generated with
git-cvsimport is incompatible with both of co
Johannes Schindelin writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> On Tue, 12 Feb 2008, Ian Jackson wrote:
> > At the very least we need one drcs branch containing only changes from
> > the upstream cvs. It has to be incrementally updated, automaticall
It seems to me that there are two questions here:
* Should the CVS for the upstream repository be replaced with
something else ?
* In the meantime, or if upstream decide not to, what is the best way
for non-upstream contributors to collaborate with each other ?
The answer to the first qu
I was doing some merging of qemu and I noticed that the block driver
backends don't check the guest's read/write attempts against the
nominal size of the block device.
I haven't checked all of the backends but I have verified the bug with
block-cow.c, which I have in my test induced to set a bitma
The attached patch makes the ide emulation actually take notice of
error returns from bdrv_write and bdrv_aio_{read,write}.
Ian.
diff --git a/block.c b/block.c
diff --git a/hw/ide.c b/hw/ide.c
index 25f5b9f..370a412 100644
--- a/hw/ide.c
+++ b/hw/ide.c
@@ -792,6 +792,11 @@ static void ide_set_sec
Daniel P. Berrange writes ("Re: [Qemu-devel] [PATCH] bdrv_flush error
handling"):
> On Wed, Feb 20, 2008 at 03:53:46PM +, Ian Jackson wrote:
> > Finally, it would perhaps be best if the block device emulators wrote
> > to the qemu console to complain if they give
The macros isupper, isspace, tolower, and so forth (from )
are defined to take an int containing the value of an unsigned char,
or EOF.
This means that you mustn't write:
char *p;
...
if (isspace(*p)) { ...
If *p is a top-bit-set character, and your host architecture has
signed chars by
bdrv_flush is declared to return void, but this is wrong because it
means that the implementations have nowhere to report their errors.
Indeed, the implementations generally ignore errors.
This patch corrects this by making it return int (implicitly, either 0
or -errno, as for other similar functi
Avi Kivity writes ("Re: [Qemu-devel] [PATCH] bdrv_flush error handling"):
> For non-raw formats, you can pass through errors on data, but it is
> impossible to recover on metadata errors, so dying on I/O error should
> be fine.
You mean metadata write errors I assume. I don't see why a metadata
Paul Brook writes ("Re: [Qemu-devel] [PATCH] bdrv_flush error handling"):
> Disk full is a fundamentally unfriendly situation to be in. There is no good
> answer. Reporting errors back to the host has its own set of problems. Many
> guest OS effectively just lock up when this occurs.
I think tha
The attached patch implements the ATA write cache feature. This
enables a guest to control, in the standard way, whether disk writes
are immediately committed to disk before the IDE command completes, or
may be buffered in the host.
In this patch, by default buffering is off, which provides bette
Jamie Lokier writes ("Re: [Qemu-devel] [PATCH] ide.c make write cacheing
controllable by guest"):
> However, I notice that it tells the guest that data is committed to
> hard storage when the host has merely called fsync().
Yes, that's what fsync is supposed to do.
> On Linux (and other host OSe
Jamie Lokier writes ("Re: [Qemu-devel] [PATCH] ide.c make write cacheing
controllable by guest"):
> I'm imagining that fdatasync() will flush the necessary metadata,
> including file size, when a file is extended. As would O_DSYNC.
Do you have a reference to support this supposition ? SuSv3's
s
Jamie Lokier writes ("Re: [Qemu-devel] [PATCH] ide.c make write cacheing
controllable by guest"):
> I agree it's a bit ambiguous. My understanding is that _increases_ in
> size are included, by convention as much as anything, since the larger
> size is necessary to retrieve the data later.
Yes.
Without `set -e', or the use of &&, errors in commands run from
Makefiles in multi-command fragments are not trapped. ( ) are
redundant in multi-command shell fragments.
Ian.
diff --git a/Makefile b/Makefile
index d74aa6e..89c4bd6 100644
--- a/Makefile
+++ b/Makefile
@@ -193,14 +193,14 @@ ifneq
Anthony Liguori writes ("[Qemu-devel] [PATCH] Support redirect -curses
> over a character driver"): I love the -curses feature but I really
> wanted to use it over a telnet: character device. This patch
> enables this and changes the syntax of the -curses argument to take
> a character device.
Su
someone more
familiar with C++ than C.
I haven't changed all of the cases, just the ones where it seemed
clear that it should be changed.
Thanks,
Ian.
Signed-off-by: Ian Jackson <[EMAIL PROTECTED]>
diff --git a/block-vvfat.c b/block-vvfat.c
index 7fe7e6a..c587bcf 100644
--- a/bl
As I think has been mentioned here a few times before, Xen is able to
support guests with more RAM than the host's (strictly, dom0's)
address space. For example, 64-bit guests with >4G RAM on 32-bit
hosts. For this and for other reasons, guest physical RAM is not
mapped into any host process.
I
argphys's extra argument.
I hope this meets with your approval.
Thanks,
Ian.
Signed-off-by: Ian Jackson <[EMAIL PROTECTED]>
---
hw/pc.c | 98 ++---
loader.c | 43 +++
sysemu.h |7 -
3 files chan
defined in libxl_internal.h.
Signed-off-by: Ian Jackson
diff -r 49deb113cd40 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c Fri Nov 13 15:46:58 2009 +
+++ b/tools/libxl/libxl.c Fri Nov 13 18:35:36 2009 +
@@ -21,8 +21,10 @@
#include
#include
#include
+#include
#include
I wrote:
> This patch makes xl create check whether qemu-dm has started
> correctly, and causes it to fail immediately with appropriate errors
> if not. There are other bugfixes too.
But I sent it to the wrong list.
Sorry,
Ian.
-unstable) will apply cleanly to qemu, but the code
generally looks very similar.
Signed-off-by: Ian Jackson <[EMAIL PROTECTED]>
Ian.
diff -r 38a45b7c6cb5 tools/ioemu/hw/vga.c
--- a/tools/ioemu/hw/vga.c Mon Dec 10 11:37:13 2007 +
+++ b/tools/ioemu/hw/vga.c Mon Dec 10 17:55:22
andrzej zaborowski writes ("Re: [Qemu-devel] [PATCH] ioemu/qemu vga: save and
restore vram buffer"):
> On 10/12/2007, Ian Jackson <[EMAIL PROTECTED]> wrote:
> > I have reinterpreted the `is_vbe' byte, which is related to
> > CONFIG_BOCHS_VBE, as a general
Ross Lagerwall writes ("Re: [PATCH v5 0/8] xen: xen-domid-restrict
improvements"):
> What's the status of this patch series? There don't seem to be many
> outstanding complaints but they haven't been pushed into master. At
> least the Xen changes have all been reviewed by Anthony (except for
>
no-re...@patchew.org writes ("Re: [Qemu-devel] [PATCH RFC 0/6] xen:
xen-domid-restrict improvements"):
> This series seems to have some coding style problems. See output below for
> more information:
Thanks for this automatic mail. I have sorted out most of these.
However:
> ERROR: consider usi
Anthony PERARD writes ("Re: [Qemu-devel] [PATCH RFC 1/6] xen: link against
xentoolcore"):
> Here is a patch that I think will work, if libxentoolcore is release in
> Xen 4.10.
Thanks very much. I have, more or less, adopted this. Thanks also
for your other comments, which I have addressed.
Ian
, because the
restriction needs to be done very late - after qemu has opened all of
its control fds.
xentoolcore_restrict_all and xentoolcore.h are available in Xen 4.10
and later, only. Provide a compatibility stub. And drop the
compatibility stubs for the old functions.
Signed-off-by: Ian Jackson
xc_interface_open etc. is not going to work if we have dropped
privilege, but xendevicemodel_shutdown will if everything is new
enough.
xendevicemodel_shutdown is only availabe in Xen 4.10 and later, so
provide a stub for earlier versions.
Signed-off-by: Ian Jackson
---
v2: Add compatibility
ction
xen_setup_post, just after os_setup_post. Also provide the
appropriate stub for when Xen compilation is disabled.
Signed-off-by: Ian Jackson
---
hw/i386/xen/xen-hvm.c | 8
hw/xen/xen-common.c | 13 +
include/sysemu/sysemu.h | 2 ++
stubs/xen-hvm.c | 5 +
I have been working on trying to get qemu, when running as a Xen
device model, to _actually_ not have power equivalent to root.
I think I have achieved this, with some limitations (which will be
discussed in my series against xen.git.
However, there are changes to qemu needed. In particular
*
ed if configure is run with bash. The
something), it is necessary to say bash ./configure to get the extra
debug info in the log.
Signed-off-by: Ian Jackson
---
configure | 4
1 file changed, 4 insertions(+)
diff --git a/configure b/configure
index 6f691df..21a2b15 100755
--- a/configure
This allows the caller to specify a uid and gid to use, even if there
is no corresponding password entry. This will be useful in certain
Xen configurations.
Signed-off-by: Ian Jackson
---
v2: Coding style fixes.
---
os-posix.c | 31 +++
qemu-options.hx | 12
1 - 100 of 301 matches
Mail list logo
