Hi,
Im trying to figure out how (on, say, x86), qemu (1.3, git) knows when
the guest has accessed a page - in particular, on a framebuffer.
It looks like its done via dirty page logs, which are maintained by the
host kernel, so probably this is a kernel question, more than a qemu one.
Is th
Hi folks,
I'm looking at dirty page logging on KVM on ARM, which appears, at
present to be non-existent. Is anyone working on this, or willing to
lend a hand?
I'm running KVM on an OMAP5, and my guest is a vexpress-a15 with PL-111
framebuffer.
running tcg mode, this works, however in KVM I
On Fri, 2011-04-22 at 13:51 +0200, Jes Sorensen wrote:
> > What kind of coding error does splitting this out aim to prevent?
> > missing break; / return; statements? Because I dont see how it
> achieves
> > that...
>
> Hiding things you miss when reading the code, it's a classic for
> people
> to
On Thu, 2011-04-21 at 08:21 -0500, Michael Roth wrote:
> >> +switch (level& G_LOG_LEVEL_MASK) {
> >> +case G_LOG_LEVEL_ERROR: return "error";
> >> +case G_LOG_LEVEL_CRITICAL: return "critical";
> >> +case G_LOG_LEVEL_WARNING: return "warning";
> >> +case
On 10/11/10 17:47, Anthony Liguori wrote:
On 11/10/2010 11:22 AM, Ian Molton wrote:
Ping ?
I think the best way forward is to post patches.
I posted links to the git trees. I can post patches, but they are
*large*. Do you really want me to post them?
To summarize what I was trying to
Ping ?
On 05/11/10 18:05, Ian Molton wrote:
On 03/11/10 18:17, Anthony Liguori wrote:
On 11/03/2010 01:03 PM, Ian Molton wrote:
Why is it better than using virtio-serial?
For one thing, it enforces the PID in kernel so the guests processes
cant screw each other over by forging the PID
On 03/11/10 18:17, Anthony Liguori wrote:
On 11/03/2010 01:03 PM, Ian Molton wrote:
Why is it better than using virtio-serial?
For one thing, it enforces the PID in kernel so the guests processes
cant screw each other over by forging the PID passed to qemu.
My current patch touches a
On 04/11/10 09:13, Alon Levy wrote:
On Wed, Nov 03, 2010 at 06:03:50PM +, Ian Molton wrote:
On 01/11/10 13:28, Anthony Liguori wrote:
On 11/01/2010 06:53 AM, Alon Levy wrote:
While we (speaking as part of the SPICE developers) want to have the same
support in our virtual GPU for 3d as
On 01/11/10 13:28, Anthony Liguori wrote:
On 11/01/2010 06:53 AM, Alon Levy wrote:
While we (speaking as part of the SPICE developers) want to have the same
support in our virtual GPU for 3d as we have for 2d, we just don't at
this point of time.
Would it be helpful to you to have /something
On 29/10/10 12:18, Rusty Russell wrote:
On Wed, 27 Oct 2010 11:30:31 pm Ian Molton wrote:
On 19/10/10 11:39, Avi Kivity wrote:
On 10/19/2010 12:31 PM, Ian Molton wrote:
2. should start with a patch to the virtio-pci spec to document what
you're doing
Where can I find that spec?
On 01/11/10 15:57, Anthony Liguori wrote:
It very much is. It supports fully visually integrated rendering (no
overlay windows) and even compositing GL window managers work fine,
even if running 3D apps under them.
Does the kernel track userspace pid and pass that information to qemu?
Yes. A
On 01/11/10 10:42, Avi Kivity wrote:
No, not really. the guest may call for the scene to be rendered at
any time and we have to wait for that to happen before we can
return the data to it.
Waiting for a response is fine, but can't the guest issue a second
batch while waiting for the first?
No
On 01/11/10 13:21, Anthony Liguori wrote:
On 11/01/2010 05:42 AM, Avi Kivity wrote:
On 10/28/2010 03:52 PM, Ian Molton wrote:
On 28/10/10 15:24, Avi Kivity wrote:
Waiting for a response is fine, but can't the guest issue a second
batch while waiting for the first?
The other sce
On 28/10/10 21:14, Anthony Liguori wrote:
If this code was invasive to qemus core, I'd say 'no way' but its just
not. and as the GL device is versioned, we can keep using it even if
the passthrough is replaced by a virtual GPU.
The virtio-gl implementation is basically duplicating virtio-seria
On 28/10/10 15:43, Anthony Liguori wrote:
On 10/28/2010 09:24 AM, Avi Kivity wrote:
On 10/28/2010 01:54 PM, Ian Molton wrote:
True, but then all that would prove is that I can write a spec to
match the code.
It would also allow us to check that the spec matches the
requirements. Those two
On 28/10/10 15:24, Avi Kivity wrote:
The caller is intended to block as the host must perform GL rendering
before allowing the guests process to continue.
Why is that? Can't we pipeline the process?
No, not really. the guest may call for the scene to be rendered at any
time and we have to w
On 28/10/10 10:27, Avi Kivity wrote:
On 10/27/2010 03:00 PM, Ian Molton wrote:
On 19/10/10 11:39, Avi Kivity wrote:
On 10/19/2010 12:31 PM, Ian Molton wrote:
2. should start with a patch to the virtio-pci spec to document what
you're doing
Where can I find that spec?
http://ozlab
On 19/10/10 11:39, Avi Kivity wrote:
On 10/19/2010 12:31 PM, Ian Molton wrote:
2. should start with a patch to the virtio-pci spec to document what
you're doing
Where can I find that spec?
http://ozlabs.org/~rusty/virtio-spec/
Ok, but I'm not patching that until theres been s
On 10/10/10 16:11, Avi Kivity wrote:
On 10/06/2010 05:59 PM, Ian Molton wrote:
This patch implements a virtio-based transport for use by a
virtualised OpenGL passthrough implementation.
The libGL and qemu-gl code to support this patch are available here:
http://gitorious.org/vm-gl-accel/qemu
On 23/04/10 18:32, Jamie Lokier wrote:
Ian Molton wrote:
You can configure any chardev to be a tcp client. I never do that though
as I find it much more convenient to configure it as server.
Perhaps thats because chardev clients are nearly useless right now
because they just die if the
On 24/04/10 02:37, Jamie Lokier wrote:
Ian Molton wrote:
Jamie Lokier wrote:
First of all: Why are your egd daemons with open connections dying
anyway? Buggy egd?
No, they aren't buggy. but occasionally, the sysadmin of said server
farms may want to, you know, update the daemon?
On 23/04/10 15:07, Gerd Hoffmann wrote:
In my usage of qemu I didn't came across a use case which needs qemu
reconnecting yet.
You're comparing apples with oranges :-)
IMHO I don't.
Well, comparing a connection where qemu is the server to one where it is
the client doesn't seem terribly v
Jamie Lokier wrote:
> Ian Molton wrote:
>>> It might make sense to have the reconnect logic in the egd chardev
>>> backend then, thereby obsoleting the socket reconnect patch.
>> Im not sure I agree there... surely there are other things which would
>> benefit
Gerd Hoffmann wrote:
> Hi,
>
>> Im not sure I agree there... surely there are other things which would
>> benefit from generic socket reconnection support (virtio-rng cant be the
>> only driver that might want to rely on a reliable source of data via a
>> socket in a server-farm type situation?)
Gerd Hoffmann wrote:
> Hi,
>
>> * the SIZE property patch:Msg-Id:<4bb206b9.80...@collabora.co.uk>
>
> Fine with me.
\o/
So should I re-post that patch, or can I count on that being folded into
mainline ?
>> * the socket reconnect patch: Msg-Id:<4b18055b.1030...@collabora.co.uk>
>
> Not
Jamie Lokier wrote:
> But enough of that: It's history now; the guest virtio-rng has existed
> for more than a year. It is also amazingly short and simple. Yay for Rusty!
Ok, so...
If we can now take steps to integrate the code...
I'd like to get some feedback (or merging!) of the other parts
Jamie Lokier wrote:
> Ian Molton wrote:
>> Jamie Lokier wrote:
>>> What do the other hypervisors supporting virtio-rng do?
>> Um. support it? Im not sure what you mean there.
>
> Do the other hypervisors do anything special to support EGD, or is it
> just treat
Jamie Lokier wrote:
Hi :-)
> Ian Molton wrote:
>> One last and quite important point - where should the EGD protocol
>> implementation go? really it needs to work as kind-of a line discipline,
>> but AFAICT thats not supported? it would be a mistake to put rate
>> li
Paul Brook wrote:
>> So, rather than bike-shedding, how about making some kind of decision?
>
> Ok, let me make this simple.
Great!
> Features such as rate limiting and EGD protocol translation should not be
> part
> of individual device emulation. They are part of the host interface, not the
Paul Brook wrote:
>> Paul Brook wrote:
>> So now everything that looks like a stream of bytes has to use the
>> virtio-serial code...
>
> IMO, yes. That's the whole point of virtio-serial.
>
> You can handle it however you like in your in your favourite guest OS, but I
> object to qemu having m
Jamie Lokier wrote:
> I would hope that the host can rate limit itself without needing apps
> to govern themselves, though.
That depends on the source of the entropy - some sources can, some are
fed to daemons that can, but not all systems have such daemons.
:)
-Ian
Paul Brook wrote:
This patch adds support for virtio-rng. Data is read from a
chardev and can be either raw entropy or received via the EGD protocol.
>>> I still don't get why you need this at all. It seems like
>>> virtio-serial would already provides everything you need.
>> I gue
Paul Brook wrote:
>>This patch adds support for virtio-rng. Data is read from a chardev
>> and can be either raw entropy or received via the EGD protocol.
>
> I still don't get why you need this at all. It seems like virtio-serial would
> already provides everything you need.
Because we
>From 5f484301d73fa53009bbcd430f8ae85868b67772 Mon Sep 17 00:00:00 2001
From: Ian Molton
Date: Tue, 17 Nov 2009 14:34:12 +
Subject: [PATCH 2/4] virtio: Add virtio-rng driver
This patch adds support for virtio-rng. Data is read from a chardev and
can be either raw entropy
>From cb0eb35564067859b6d596f3beea4e8486ad9f99 Mon Sep 17 00:00:00 2001
From: Ian Molton
Date: Tue, 17 Nov 2009 14:10:10 +
Subject: [PATCH 1/4] Add SIZE type to qdev properties
This patch adds a 'SIZE' type property to those available to qdevs.
It is the analogue of
Hi!
I've cleaned up and rebased the virtio-rng patch, including the
comments made on the previous version.
I've dropped socket reconnect support because I don't have the
time to make it into some kind of generic does-everything
subsystem, so here is whats left - a pure rng / egd device.
-Ian
Alexander Graf wrote:
> I guess what you really want is some shm region between host and guess
> that you can use as ring buffer. Then you could run a timer on the host
> side to flush it or have some sort of callback when you urgently need to
> flush it manually.
>
> The benefit here is that you
Anthony Liguori wrote:
> On 02/22/2010 10:46 AM, Ian Molton wrote:
>> Anthony Liguori wrote:
>>
>>
>>> cpu_physical_memory_map().
>>>
>>> But this function has some subtle characteristics. It may return a
>>> bounce buffer if you at
Anthony Liguori wrote:
> cpu_physical_memory_map().
>
> But this function has some subtle characteristics. It may return a
> bounce buffer if you attempt to map MMIO memory. There is a limited
> pool of bounce buffers available so it may return NULL in the event that
> it cannot allocate a boun
Hi folks,
I've been updating some old patches which make use of a function to
translate guest virtual addresses into pointers into the guest RAM.
As I understand it qemu has guest virtual and physical addresses, the
latter of which map somehow to host ram addresses.
The function which the code h
Ian Molton wrote:
>>> +static void virtio_rng_save(QEMUFile *f, void *opaque)
>>> +{
>>> +VirtIORng *s = opaque;
>>> +
>>> +virtio_save(&s->vdev, f);
>>> +}
>>> +
>>> +static int virtio_rng_load(Q
Anthony Liguori wrote:
> I'm all for doing things incrementally but there has to be a big picture
> that the incremental bit fits into otherwise you end up with a bunch of
> random features that don't work together well.
Well, if you just add stuff without ever changing anything that went
before,
Anthony Liguori wrote:
>> +DEFINE_RNG_PROPERTIES(VirtIOPCIProxy, rng),
>>
>
> I don't see any reason to use a define here.
Consistency with the other virtio code (at the time I wrote it)
> Coding style is off here (newline between ) and { ).
Fixed.
> Can't call gettimeofday di
Anthony Liguori wrote:
> I went back and looked at the last series and found my feedback. I had
> suggested that instead of automatically reconnecting, a mechanism should
> be added for a user to initiate a reconnect.
This sounds useful
> Additionally, we should emit events upon disconnect thro
Gerd Hoffmann wrote:
> Hi,
>
>>> + PCI_VENDOR_ID_REDHAT_QUMRANET,
>>> + PCI_DEVICE_ID_VIRTIO_RNG,
>>
>> Gerd (or the right person at Red Hat) needs to Ack the assignment of
>> this PCI device id.
>
> Using the first unused one should be ok, I'll double check that though.
> pci-ids.txt must be u
Add a reconnect option that allows sockets to reconnect (after a
specified delay) to the specified server. This makes the virtio-rng driver
useful in production environments where the EGD server may need to be restarted.
Signed-off-by: Ian Molton
---
qemu-char.c | 159
This patch addresses a build issue due to a missing include in
fpu/softfloat-native.c
Signed-off-by: Ian Molton
---
fpu/softfloat-native.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fpu/softfloat-native.c b/fpu/softfloat-native.c
index 8d64f4e..702950e
This patch adds support for virtio-rng. Data is read from a chardev and
can be either raw entropy or received via the EGD protocol.
Signed-off-by: Ian Molton
---
Makefile.target |2 +-
hw/pci.h|1 +
hw/virtio-pci.c | 27 +++
hw/virtio-rng.c | 202
This patch adds a 'SIZE' type property to those available to qdevs.
It is the analogue of the OPT_SIZE property for options.
Signed-off-by: Ian Molton
---
hw/qdev-properties.c | 34 ++
hw/qdev.h|4
pars
This patch rationalises the declaration of inet_listen_opts such that
it matches the other inet_{listen,connect}_opts functions.
This change is needed for a patch adding socket reconection support.
Signed-off-by: Ian Molton
---
qemu-sockets.c |9 +++--
qemu_socket.h |2
The following patches are an update of my virtio-rng patchset.
Patches 1-3 implement needed infrastructure fpr virtio-rng to be used
effectively, patch 4 implements the device.
Patch 5 is a build fix I needed in order to compile -git qemu.
Please apply :)
qemu-sockets.c |9 +-
qem
Ian Molton wrote:
Can I get the status of this patchset please ?
Thanks!
> This patch rationalises the declaration of inet_listen_opts such that
> it matches the other inet_{listen,connect}_opts functions.
>
> This change is needed for a patch adding socket reconec
Add a reconnect option that allows sockets to reconnect (after a
specified delay) to the specified server. This makes the virtio-rng driver
useful in production environments where the EGD server may need to be restarted.
Signed-off-by: Ian Molton
---
qemu-char.c | 159
This patch adds a 'SIZE' type property to those available to qdevs.
It is the analogue of the OPT_SIZE property for options.
Signed-off-by: Ian Molton
---
hw/qdev-properties.c | 34 ++
hw/qdev.h|4
pars
This patch adds support for virtio-rng. Data is read from a chardev and
can be either raw entropy or received via the EGD protocol.
Signed-off-by: Ian Molton
---
Makefile.target |2 +-
hw/pci.h|1 +
hw/virtio-pci.c | 27 +++
hw/virtio-rng.c | 202
This patch rationalises the declaration of inet_listen_opts such that
it matches the other inet_{listen,connect}_opts functions.
This change is needed for a patch adding socket reconection support.
Signed-off-by: Ian Molton
---
qemu-sockets.c |9 +++--
qemu_socket.h |2
Reposting for inclusion into qemu for the next release (hopefully)
I've rebased against master and rediffed. Since we've missed 0.12 I've reordered
the patches so that virtio-rng depends on the socket reconnect patches,
and has the matching functionality thats needed to handle reconnect events.
T
Anthony Liguori wrote:
> The QEMU team is pleased to announce the availability of the 0.12.0-rc1
> release. This is the first release candidate for the 0.12.0 release.
> This release is not intended for production use.
What git tree should I rebase my patches onto (for the next release) ?
Thanks
Markus Armbruster wrote:
> The place for verbose device names is DeviceInfo member desc. The
> name should be short & sweet.
Agreed, however...
Why do these (maybe others) get caps in their names? they dont look
right to me, compared to the others with nice names like usb-serial,
piix-ide, or c
Jamie Lokier wrote:
> If the system as a whole runs out of memory so that no-overcommit
> malloc() fails on a small alloc, there's a good chance that you won't
> be able to send a message to the host
Send what message to the host? If the malloc in the socet reconnect code
fails, its the code on t
Jamie Lokier wrote:
> Ian Molton wrote:
>>>> Besides, not all entropy comes from /dev/random.
> Those arguments are weak.
No worse than the counterarguments.
If nothing else, qemu is a useful tool for testing kernel subsystems and
in fact the virtio code triggered and ca
malc wrote:
> Well, i don't have a swap...
Indeed, nor do I (machine has an NFS root. swap on NFS is... not good.)
Avi Kivity wrote:
> Init is pretty easy to handle. I'm worried about runtime where you
> can't report an error to the guest. Real hardware doesn't oom.
In the case of the socket reconnect code I posted recently, if the
allocation failed, it would give up trying to reconnect and inform the
user
Avi Kivity wrote:
> On 12/06/2009 01:25 AM, Ian Molton wrote:
>> Avi Kivity wrote:
>>
>>
>>> It's not that it doesn't have a way to report failure, it's that it
>>> doesn't fail. Do you prefer functions that fail and report it to
&g
Markus Armbruster wrote:
> p = malloc(n * sizeof(struct foo);
> if (n && !p)
> exit_no_mem();
> for (i = 0; i < n; i++)
> compute_one(p, i);
>
> With qemu_malloc(), the error handling moves into qemu_malloc():
>
> p = qemu_malloc(n * sizeof(struct foo);
> for
Jamie Lokier wrote:
> Ian Molton wrote:
>> Jamie Lokier wrote:
>>
>>> I'm a bit puzzled.
>>>
>>> Why isn't virtio-rng getting entropy from /dev/random on the host?
>> /dev/random may not be available.
>
> Understood on a non-
Avi Kivity wrote:
> It's not that it doesn't have a way to report failure, it's that it
> doesn't fail. Do you prefer functions that fail and report it to
> functions that don't fail?
You have a way of allocating memory that will _never_ fail?
>> Seriously, who does that anyway? why call malloc
Avi Kivity wrote:
> Only if you allocate using POSIX malloc(). If you allocate using a
> function that is defined to return a valid pointer for zero length
> allocations, you're happy.
Wouldnt it be better to, rather than use a qemu_malloc() that is utterly
counterintuitive in that it has no way
Ian Molton wrote:
> Anthony Liguori wrote:
>
> New patch attached, addressing the below. Thanks!
Did this patch make it? I cant seem to find my earlier patches in the
.git repo you mentioned, does that mean they have been dropped, or that
they have been merged upstream ?
I can repost
I've reordered it so the new code needs
the forward dec. rather than adding one for the old code.
> Mixing tabs and spaces.
fixed.
>From 8d12cabf09996eef9adcc121ea3cbec70d48b3b4 Mon Sep 17 00:00:00 2001
From: Ian Molton
Date: Tue, 1 Dec 2009 11:18:41 +
Subject: [PATCH 2/4] socket
base this and its
prerequisite.
>From 05581c5badd693b7537fe57f85a2ff5ddcb7972d Mon Sep 17 00:00:00 2001
From: Ian Molton
Date: Tue, 1 Dec 2009 11:18:41 +
Subject: [PATCH 2/4] socket: Add a reconnect option.
Add a reconnect option that allows sockets to reconnect (after a
specified delay) to the sp
how to get t-bird to inline patches?
-Ian
>From e9d4be9cd0ef9e34c65939d4604874035c45bf34 Mon Sep 17 00:00:00 2001
From: Ian Molton
Date: Tue, 1 Dec 2009 11:18:41 +
Subject: [PATCH 2/4] socket: Add a reconnect option.
Add a reconnect option that allows sockets to reconnect (after a
sp
Anthony Liguori wrote:
> Ian Molton wrote:
> Actually, that patch would break a production environment. You cannot
> sleep in qemu. It will severely impact the guest.
I refer to the version posted today, which doesnt sleep, but uses a
timer instead. (or did I miss something and
Anthony Liguori wrote:
> I've got all of the patches I'm considering for 0.12 currently in
> staging.
> http://repo.or.cz/w/qemu/aliguori-queue.git
I see you have my rng and size patches in there, thanks for the quick
review!
Is it too late to get the timer based socket reconnect patch in and th
p 17 00:00:00 2001
From: Ian Molton
Date: Tue, 1 Dec 2009 11:18:41 +
Subject: [PATCH 2/4] socket: Add a reconnect option.
Add a reconnect option that allows sockets to reconnect (after a
specified delay) to the specified server. This makes the virtio-rng driver
useful in production environmen
Krumme, Chris wrote:
> Hello Ian,
Hi!
> Should you be introducing a while sleep loop into Qemu here?
>
> I would think you should be returning 'no data', maybe after trying
> once.
Indeed.
I could have sworn I tried that. Too much crack, will re-do.
Jamie Lokier wrote:
> I'm a bit puzzled.
>
> Why isn't virtio-rng getting entropy from /dev/random on the host?
/dev/random may not be available. Besides, not all entropy comes from
/dev/random.
-Ian
Anthony Liguori wrote:
> Ian Molton wrote:
>> Hi folks,
>>
>> I need my source of data for virtio-rng to be reliable - IOW. if the
>> server dies and comes back up, I want qemu to reconnect and suck down
>> fresh entropy, rather than hand the rngd process on the g
Hi folks,
I need my source of data for virtio-rng to be reliable - IOW. if the
server dies and comes back up, I want qemu to reconnect and suck down
fresh entropy, rather than hand the rngd process on the guest.
I'm using the chardev 'socket' type to make the connection to the host.
Would a patc
Ian Molton wrote:
> This patch adds support for virtio-rng. Data is read from a chardev and
> can be either raw entropy or received via the EGD protocol.
No comments?
This patch adds support for virtio-rng. Data is read from a chardev and
can be either raw entropy or received via the EGD protocol.
Signed-off-by: Ian Molton
---
Makefile.target |2 +-
hw/pci.h|1 +
hw/virtio-pci.c | 27
hw/virtio-rng.c | 194
Hi folks,
This patch is a first cut at a driver for virtio-rng. Its not problem free, but
it works.
Features:
* Raw and EGD protocol support
* Rate limiting (simple)
Known problems:
* provokes a bug in the kernels virtio-rng driver that results in data
corruption.
* Does not reconnect to the
Stefan Weil wrote:
> A code review run by Steve Grubb complained about code in e1000.c:
>
> In hw/e1000.c at line 89, vlan is declared to be 4 bytes.
> At line 382 is an attempt to do a memmove over it with a size of 12.
> +/* Fields vlan and data must not be reordered or separated. */
>
This patch adds a 'SIZE' type property to those available to qdevs.
It is the analogue of the OPT_SIZE property for options.
Signed-off-by: Ian Molton
---
hw/qdev-properties.c | 34 ++
hw/qdev.h|4
pars
Gerd Hoffmann wrote:
> On 11/17/09 15:23, Ian Molton wrote:
>> I've cooked up this patch (attached) to add a SIZE property to qdevs.
>> I've kept the same semantics as the OPT_SIZE parser for now.
>
> The error message should be adapted (s/Option/Property/ at least)
Paul Brook wrote:
> On Tuesday 17 November 2009, Ian Molton wrote:
> When do we ever have a value that can be specified as both bits and bytes? I
> don't think it makes sense to specify this. The fact that we accept a "b"
> suffix at all is suspicious.
Well, entropy
Hi,
Qemu currently is making a bit of a hash of parsing suffixes,
Right now, it has:
T, G, M, and K which are multiples of 1024 bytes - fair enough
but it also has:
k - 1024 (should be 1000)
and b:
Byte (also wrong)
since its only using a single character, with b taken, theres no way to
r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Amit Shah wrote:
> (Any reason to take this off-list?)
None other than hitting reply rather than reply-all. CCing list once
more :-)
>> Either way, you still need to specify the properties - they've just
>> moved into the console driver in your patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jamie Lokier wrote:
> Ian Molton wrote:
>
> With VMs, in some circumstances it might be preferable to trust the
> host when it says it's providing already-tested entropy. After all
> the host has total control over the guest
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jamie Lokier wrote:
> Ian Molton wrote:
>> Heres my patch to virtio-console. The device is now specified like this:
>>
>> - -chardev file,path=/path/to/testfile,id=test
>> - -device virtio-console-pci,chardev=test
Note,
3CGXrFGb8WJjt1Rb0DXvHbr2Z8Wdn
2PwPSOliAY0iPfzo79Ke
=TM+C
-END PGP SIGNATURE-
>From 40a7a43484176194490a7980741a6d4764c10fb1 Mon Sep 17 00:00:00 2001
From: Ian Molton
Date: Mon, 16 Nov 2009 17:49:18 +
Subject: [PATCH] virtio-console: Remove ugly device reg. hack
This patch removes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerd Hoffmann wrote:
> Hi,
Hi!
Thanks for your reply - I should have posted to say I'd partially solved
this. I have a question though,
> Use a chardev property (look at serial.c, "isa-serial" device).
>
> Then you'll configure it on the qemu com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Further investigation seems to have highlighted the problem:
My code is correctly decoding the OPT_SIZE parameter into the
'value.uint' field in a QemuOpt
I've also got the devices properties set up, so that the device may
receive its data.
Eg.
in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I'm trying to use the qption parser to parse my device option string,
which is formatted like this:
- -vrng dev=/dev/foo,rate=10K
and I mostly got things to work by using this, in vl.c:
static int virtio_rng_parse(const char *arg)
{
Qem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin Wolf wrote:
> I think in general qemu is poorly commented.
I think thats a bit of an understatement. in particular I'm finding the
options code to be a nightmare. Hopefully I'll be fixing some of that in
my upcomming submissions.
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi folks,
I'm writing a virtio-rng host-side driver for qemu-kvm, and I've got
something up and running that works, and will pass data gathered from a
char device on the host through to the virtio-rng driver on a guest copy
of linux.
Ultimately it'll
96 matches
Mail list logo
