Re: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO
Avi Kivity wrote: Ian Jackson wrote: Avi Kivity writes ([Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO): Newer Xen shouldn't have this problem though; it runs qemu in kernel mode in a dedicated 64-bit domain. I think there is continued value in being able to emulate a guest whose physical address space exceeds the virtual address space in the host. The whole assumption that all guest accessible RAM is mapped at once, contiguously, is I think wrong. I agree that we shouldn't expect memory to be contiguous, in order to properly support hotplug. But I see zero value in trying to support large memory configurations on 32-bit in 2008. This is what 64-bit systems are for! If Xen has a problem with 64-bit hosts, we can try to accommodate it, but to have 32-bit qemu/tcg Running x86-64 binaries on a (non-x86) 32-bit host is IMHO quite an obvious application for qemu/tcg. or qemu/kvm support large address spaces is pointless IMO. Interestingly, Virtualbox just started to support 64-bit-target-on-32-bit-host. Thiemo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Vmchannel PCI device.
Daniel P. Berrange wrote: [snip] If you don't have QEMU as a broker, it makes it very hard for QEMU to virtualization all of the resources exposed to the guest. This complicates things like save/restore and complicates security policies since you now have things being done on behalf of a guest originating from another process. It generally breaks the model of guest-as-a-process. This really depends on what you define the semantics of the vmchannel protocol to be - specifically whether you want save/restore/migrate to be totally opaque to the guest or not. I could imagine one option is to have the guest end of the device be given -EPIPE when the backend is restarted for restore/migrate, and choose to re-establish its connection if so desired. This would not require QEMU to maintain any backend state. For stateless datagram (UDP-like) application protocols there's nothing that there's no special support required for save/restore. What's the argument to do these things external to QEMU? There are many potential uses cases for VMchannel, Could you describe a practical use case of VMchannel in Qemu? I think I missed what this feature is good for. :-) not all are going to be general purpose things that everyone wants to use. If it is only good for specialized esoteric stuff, why should it be in Qemu? Thiemo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] Fix off-by-one bug limiting VNC passwords to 7 chars
Chris Webb wrote:
Fix off-by-one bug limiting VNC passwords to 7 characters instead of 8
monitor_readline expects buf_size to include the terminating \0, but
do_change_vnc in monitor.c calls it as though it doesn't. The other site
where monitor_readline reads a password (in vl.c) passes the buffer length
correctly.
Signed-off-by: Chris Webb [EMAIL PROTECTED]
---
monitor.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/monitor.c b/monitor.c
index 22360fc..6ae5729 100644
--- a/monitor.c
+++ b/monitor.c
@@ -433,7 +433,7 @@ static void do_change_vnc(const char *target)
if (strcmp(target, passwd) == 0 ||
strcmp(target, password) == 0) {
char password[9];
- monitor_readline(Password: , 1, password, sizeof(password)-1);
+ monitor_readline(Password: , 1, password, sizeof(password));
password[sizeof(password)-1] = '\0';
The next line can go as well, the string is already NULL terminated.
Thiemo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
