Re: [Qemu-devel] [PATCHv2 3/4] cpuid: disable pv eoi for 1.1 and older compat types
On Tue, 28 Aug 2012, Michael S. Tsirkin wrote: On Mon, Aug 27, 2012 at 07:40:56PM +, Blue Swirl wrote: On Mon, Aug 27, 2012 at 7:24 PM, Michael S. Tsirkin m...@redhat.com wrote: On Mon, Aug 27, 2012 at 07:12:27PM +, Blue Swirl wrote: On Mon, Aug 27, 2012 at 7:06 PM, Michael S. Tsirkin m...@redhat.com wrote: On Mon, Aug 27, 2012 at 06:58:29PM +, Blue Swirl wrote: On Mon, Aug 27, 2012 at 12:20 PM, Michael S. Tsirkin m...@redhat.com wrote: In preparation for adding PV EOI support, disable PV EOI by default for 1.1 and older machine types, to avoid CPUID changing during migration. PV EOI can still be enabled/disabled by specifying it explicitly. Enable for 1.1 -M pc-1.1 -cpu kvm64,+kvm_pv_eoi Disable for 1.2 -M pc-1.2 -cpu kvm64,-kvm_pv_eoi Signed-off-by: Michael S. Tsirkin m...@redhat.com --- hw/Makefile.objs | 2 +- hw/cpu_flags.c| 32 hw/cpu_flags.h| 9 + hw/pc_piix.c | 2 ++ [..snip..] No leading underscores. They are not used in QEMU. They are *widely* used in QEMU to mark internal stuff. E.g. parameters in many macros. ISO/IEC 9899:TC3 7.1.3#1 - All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use. IOW no __ or _[A-Z] at all. - All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces. IOW _ as the name of an argument to a macro is (probably) okay. In reality __ is also widely used. I'm still mulling removing 2.4 from HACKING - it appears too draconian, the chances of a conflict with preprocessor are remote and if it triggers, it's trivial to catch. We also have lots of existing code violating this rule. And the rule about _t suffix is just silly. http://pubs.opengroup.org/onlinepubs/7908799/xns/namespace.html [..snip..] -- mailto:av1...@comtv.ru -- 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 4/4] kvm: i386: Add classic PCI device assignment
On Tue, 28 Aug 2012, Anthony Liguori wrote:
Blue Swirl blauwir...@gmail.com writes:
On Tue, Aug 28, 2012 at 5:28 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Aug 28, 2012 at 05:01:55PM +, Blue Swirl wrote:
On Tue, Aug 28, 2012 at 7:35 AM, Michael Tokarev m...@tls.msk.ru wrote:
On 27.08.2012 22:56, Blue Swirl wrote:
[]
+static uint32_t slow_bar_readb(void *opaque, target_phys_addr_t addr)
+{
+AssignedDevRegion *d = opaque;
+uint8_t *in = d-u.r_virtbase + addr;
Don't perform arithmetic with void pointers.
There are a few places in common qemu code which does this for a very
long time. So I guess it is safe now.
It's a non-standard GCC extension.
So? We use many other GCC extensions. grep for typeof.
Dependencies should not be introduced trivially. In this case, it's
pretty easy to avoid void pointer arithmetic as Jan's next version
shows.
The standard is vague with respect void arithmetic. Most compilers
allow it. A very good analysis of the standard can be found below.
http://stackoverflow.com/questions/3523145/pointer-arithmetic-for-void-pointer-in-c
BTW: can we please stop arguing about C standards. If we currently are
using something in QEMU that's supported by clang and GCC, it's fine and
we ought to continue using it.
No we can not stop arguing. Besides you are wrong.
[..snip..]
--
mailto:av1...@comtv.ru
--
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-kvm 1.1.1 hangs using 100% CPU when using ES1370 emulation
On Fri, 24 Aug 2012, Michael Tokarev wrote: Hello Mike, Vassili. On 23.08.2012 20:16, Mike Gerber wrote: Hi, I'm using a KVM guest to stream audio using darkice to an icecast2 server on the same guest. The guest uses an emulated ES1370 sound card to capture the host's audio input (ASUS Xonar DX) using the ALSA backend. After 1 or 2 days, the qemu-kvm process locks up, using up 100% CPU, apparently spinning in audio/rate_template.h (See gdb session below). Do you have any advice on how to solve this problem? I haven't tried the -no-kvm-* switches, please advice if that would be useful in this case. Unfortunately it takes up to 2 days for the bug to happen, so trying all possible configurations is a bit time-consuming. More information here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685353 Mike, I noticed your work trying to debug the issue, and you finally succeeded to get a usable backtrace which is good. I just weren't able to get to you earlier. Can you also check whenever hda emulated device also shows this issue? Vassili, can you take a look please - the prob appears to be somehow sound-related.. [..snip..] It's also (appears) to be in the chunk of code written by Fabrice not me. Last comment at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685353 doesn't include a backtrace. Question - what's the frequency that the emulated card is operated in (and what is the actual frequency host card provides)? -- mailto:av1...@comtv.ru -- 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] KVM call agenda for tuesday 31
On Mon, 5 Mar 2012, Blue Swirl wrote: On Mon, Mar 5, 2012 at 15:17, Avi Kivity a...@redhat.com wrote: On 03/05/2012 05:15 PM, Anthony Liguori wrote: The other alternative is to s/target_phys_addr_t/uint64_t/ in the memory API. I think 32-on-32 is quite rare these days, so it wouldn't be much of a performance issue. I think this makes sense independent of other discussions regarding fixing target_phys_addr_t size. Hardware addresses should be independent of the target. If we wanted to use a hw_addr_t that would be okay too. Would this hw_addr (s/_t$//, or you'll be Blued) be fixed at uint64_t Malced? Posixed? Heh, a_moo would be Malced, no _t is Posixed indeed. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [RFC][PATCH 11/45] msi: Factor out delivery hook
On Tue, 18 Oct 2011, Michael S. Tsirkin wrote:
On Tue, Oct 18, 2011 at 02:23:29PM +0200, Jan Kiszka wrote:
On 2011-10-18 14:05, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 09:15:47PM +0200, Jan Kiszka wrote:
On 2011-10-17 15:43, Michael S. Tsirkin wrote:
On Mon, Oct 17, 2011 at 11:27:45AM +0200, Jan Kiszka wrote:
diff --git a/hw/msi.c b/hw/msi.c
index 3c7ebc3..9055155 100644
--- a/hw/msi.c
+++ b/hw/msi.c
@@ -40,6 +40,14 @@
/* Flag for interrupt controller to declare MSI/MSI-X support */
bool msi_supported;
+static void msi_unsupported(MSIMessage *msg)
+{
+/* If we get here, the board failed to register a delivery
handler. */
+abort();
+}
+
+void (*msi_deliver)(MSIMessage *msg) = msi_unsupported;
+
How about we set this to NULL, and check it instead of the bool
flag?
Yeah. I will introduce
bool msi_supported(void)
{
return msi_deliver != msi_unsupported;
}
OK?
Jan
Looks a bit weird ...
NULL is a pretty standard value for an invalid pointer, isn't it?
Save us the runtime check and is equally expressive and readable IMHO.
Jan
Do we need to check?
NULL dereference leads to a crash just as surely...
Not universally (not on AIX for instance (read)).
--
mailto:av1...@comtv.ru
--
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 v4 14/39] ac97: convert to memory API
On Mon, 8 Aug 2011, Avi Kivity wrote: fixes BAR sizing as well. I'm fine with this version, thanks. [..snip..] -- mailto:av1...@comtv.ru -- 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 v4 17/39] es1370: convert to memory API
On Mon, 8 Aug 2011, Avi Kivity wrote: Fine with this too, thanks. [..snip..] -- mailto:av1...@comtv.ru -- 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] Introduce short names for fixed width integer types
On Mon, 8 Aug 2011, Peter Maydell wrote: On 8 August 2011 13:56, Avi Kivity a...@redhat.com wrote: QEMU deals with a lot of fixed width integer types; their names (uint64_t etc) are clumsy to use and take up a lot of space. Following Linux, introduce shorter names, for example U64 for uint64_t. Strongly disagree. uint64_t c are standard types and it's immediately clear to a competent C programmer what they are. Random qemu-specific funny named types just introduces an unnecessary level of indirection. We only just recently managed to get rid of the nonstandard typenames for these from fpu/... Seconded. -- mailto:av1...@comtv.ru -- 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 v3 14/39] ac97: convert to memory API
On Fri, 5 Aug 2011, Anthony Liguori wrote: On 08/04/2011 08:06 AM, Avi Kivity wrote: fixes BAR sizing as well. Reviewed-by: Richard Hendersonr...@twiddle.net Signed-off-by: Avi Kivitya...@redhat.com Reviewed-by: Anthony Liguori aligu...@us.ibm.com Malc, please Ack Ok, please notify me when this is pushed so i can correct the formatting consistency issues. [..snip..] -- mailto:av1...@comtv.ru -- 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] memory: use signed arithmetic
On Tue, 2 Aug 2011, Avi Kivity wrote: When trying to map an alias of a ram region, where the alias starts at address A and we map it into address B, and A B, we had an arithmetic underflow. Because we use unsigned arithmetic, the underflow converted into a large number which failed addrrange_intersects() tests. The concrete example which triggered this was cirrus vga mapping the framebuffer at offsets 0xc-0xc7fff (relative to the start of the framebuffer) into offsets 0xa (relative to system addres space start). With our favorite analogy of a windowing system, this is equivalent to dragging a subwindow off the left edge of the screen, and failing to clip it into its parent window which is on screen. Fix by switching to signed arithmetic. http://stackoverflow.com/questions/3679047/integer-overflow-in-c-standards-and-compilers In other words UB land [..snip..] -- mailto:av1...@comtv.ru -- 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] Introduce QEMU_NEW()
On Mon, 25 Jul 2011, Alexander Graf wrote: On 25.07.2011, at 12:09, Avi Kivity wrote: On 07/25/2011 01:04 PM, Alexander Graf wrote: On 25.07.2011, at 12:02, Avi Kivity wrote: On 07/25/2011 12:56 PM, Alexander Graf wrote: That argument can be used to block any change. You'll get used to it in time. The question is, is the new interface better or not. I agree that it keeps you from accidently malloc'ing a struct of pointer size. But couldn't we also just add this to checkpatch.pl? Better APIs trump better patch review. Only if you enforce them. The only sensible thing for QEMU_NEW (despite the general rule of upper case macros, I'd actually prefer this one to be lower case though since it's so often used) would be to remove qemu_malloc, declare malloc() as unusable and convert all users of qemu_malloc() to qemu_new(). Some qemu_mallocs() will remain (allocating a byte array or something variable sized). Right. But then we really do need a check in checkpatch.pl to see if someone's using qemu_new for simple structs. I agree qemu_new() will be nicer, but that will have to wait until Blue is several light-days away from Earth. Blue, any disagreement on adding qemu_new() as a macro? Something used that often in upper case would seriously disturb the reading flow :) So do not use it then, macros should be uppercase. -- mailto:av1...@comtv.ru -- 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] Introduce QEMU_NEW()
On Mon, 25 Jul 2011, Anthony Liguori wrote: On 07/25/2011 09:30 AM, Max Filippov wrote: qemu_malloc() is type-unsafe as it returns a void pointer. Introduce QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. Just use g_new() and g_new0() These bypass qemu_malloc(). Are we okay with that? Yes. We can just make qemu_malloc use g_malloc. It would be also possible to make g_malloc() use qemu_malloc(). That way we could keep the tracepoints which would lose their value with g_malloc() otherwise. Or just add tracepoints to g_malloc()... But yeah, the point is, we ought to unify to a standard library function instead of inventing our own version of everything. What about zero-size allocations for which g_malloc would return NULL? Using a standard, well documented, rich interface trumps any arguments about the semantics of zero-sized allocation. Right right.. only g_new aborts on zero.. -- mailto:av1...@comtv.ru -- 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] Introduce QEMU_NEW()
On Mon, 25 Jul 2011, Avi Kivity wrote: On 07/25/2011 05:47 PM, malc wrote: Right right.. only g_new aborts on zero.. If n_structs is 0 it returns NULL http://developer.gnome.org/glib/2.28/glib-Standard-Macros.html#NULL:CAPS. Right you are. It's annoying that it takes this parameter at all, but I can live with it. n_structs? -- mailto:av1...@comtv.ru -- 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 11/23] memory: add ioeventfd support
On Mon, 25 Jul 2011, Avi Kivity wrote:
As with the rest of the memory API, the caller associates an eventfd
with an address, and the memory API takes care of registering or
unregistering when the address is made visible or invisible to the
guest.
Signed-off-by: Avi Kivity a...@redhat.com
[..snip..]
+static bool memory_region_ioeventfd_before(MemoryRegionIoeventfd a,
+ MemoryRegionIoeventfd b)
+{
+if (a.addr.start b.addr.start) {
+return true;
+} else if (a.addr.start b.addr.start) {
+return false;
+} else if (a.addr.size b.addr.size) {
+return true;
+} else if (a.addr.size b.addr.size) {
+return false;
+} else if (a.match_data b.match_data) {
+return true;
+} else if (a.match_data b.match_data) {
+return false;
+} else if (a.match_data) {
+if (a.data b.data) {
+return true;
+} else if (a.data b.data) {
+return false;
+}
+}
+if (a.fd b.fd) {
+return true;
+} else if (a.fd b.fd) {
+return false;
+}
Braces..
+return false;
+}
+
[..snip..]
--
mailto:av1...@comtv.ru
--
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 11/23] memory: add ioeventfd support
On Mon, 25 Jul 2011, Avi Kivity wrote:
On 07/25/2011 06:16 PM, malc wrote:
On Mon, 25 Jul 2011, Avi Kivity wrote:
As with the rest of the memory API, the caller associates an eventfd
with an address, and the memory API takes care of registering or
unregistering when the address is made visible or invisible to the
guest.
Signed-off-by: Avi Kivitya...@redhat.com
[..snip..]
+static bool memory_region_ioeventfd_before(MemoryRegionIoeventfd a,
+ MemoryRegionIoeventfd b)
+{
+if (a.addr.start b.addr.start) {
+return true;
+} else if (a.addr.start b.addr.start) {
+return false;
+} else if (a.addr.size b.addr.size) {
+return true;
+} else if (a.addr.size b.addr.size) {
+return false;
+} else if (a.match_data b.match_data) {
+return true;
+} else if (a.match_data b.match_data) {
+return false;
+} else if (a.match_data) {
+if (a.data b.data) {
+return true;
+} else if (a.data b.data) {
+return false;
+}
+}
+if (a.fd b.fd) {
+return true;
+} else {
if (a.fd b.fd) {
+return false;
+}
}
Braces..
Where? add? remove?
You authored the coding_style document btw.
--
mailto:av1...@comtv.ru
--
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 11/23] memory: add ioeventfd support
On Mon, 25 Jul 2011, Avi Kivity wrote:
On 07/25/2011 06:22 PM, malc wrote:
+}
+if (a.fd b.fd) {
+return true;
+} else {
if (a.fd b.fd) {
+return false;
+}
}
CODING_STYLE permits braceless else if.
The example uses it, the text however suggests it's illegal.
[..snip..]
--
mailto:av1...@comtv.ru
--
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] [RFC v3 31/56] ac97: convert to memory API
On Mon, 11 Jul 2011, Avi Kivity wrote:
On 07/11/2011 04:42 AM, Anthony Liguori wrote:
On 07/10/2011 03:33 PM, malc wrote:
On Sun, 10 Jul 2011, Avi Kivity wrote:
fixes BAR sizing as well.
I find this patch disgusting, the read and write handlers in particular.
Shouldn't it be possible to do something like:
typedef struct OldMemoryRegionOps {
MemoryRegionOps parent_ops;
CPUReadMemoryFunc *readfn[3];
CPUWriteMemoryFunc *writefn[3];
void *opaque;
} OldMemoryRegionOps;
That should allow old-style implementations to be converted without
introducing trampoline functions everywhere.
Here's a new version:
This one looks acceptable[1], original submission said:
fixes BAR sizing as well. what was wrong with it?
[..snip..]
P.S. Sans minor inconsistency with trailing commas.
--
mailto:av1...@comtv.ru
--
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] [RFC v3 31/56] ac97: convert to memory API
On Sun, 10 Jul 2011, Avi Kivity wrote: fixes BAR sizing as well. I find this patch disgusting, the read and write handlers in particular. [..snip..] -- mailto:av1...@comtv.ru -- 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: assigned EHCI USB headset not working
On Thu, 9 Jun 2011, Jan Kiszka wrote: On 2011-06-09 17:13, malc wrote: On Thu, 9 Jun 2011, Jan Kiszka wrote: [..snip..] Sound output over (at least) ALSA is not smoothly working in polled mode. It's similar to [1], which is yet unsolved. Jan [1] http://thread.gmane.org/gmane.comp.emulators.qemu/52365 I've lost the mail from that period, have you sent me the info i've requested? In any case, please do provide detailed information on how to reproduce this (not involving windows guests though, i don't have those) -- mailto:av1...@comtv.ru -- 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: assigned EHCI USB headset not working
On Thu, 9 Jun 2011, Jan Kiszka wrote: On 2011-06-09 09:08, Andr? Weidemann wrote: Hi Jan, On 09.06.2011 08:53, Jan Kiszka wrote: On 2011-06-09 08:19, Andr? Weidemann wrote: Hi Gerd, On 08.06.2011 14:49, Gerd Hoffmann wrote: Hi, The sound device shows up under Windows7 and drivers are installed automatically. Unfortunately it does not work. All the players I tried, did not even start playing the sound file, although they detected the DirectSound Device. iso xfer's from usb-linux via ehci are flaky for reasons not yet tracked down. Any reason why you don't just plug in a virtual sound card? The HDA emulation should work fine with win7. Using the hda driver was my first attempt. But the result was not very convincing. When playing mp3s inside the VM, I could hear music coming from the speakers, but the sound was very choppy and too slow. It was no joy listening to it. Does export QEMU_AUDIO_DAC_TRY_POLL=0 before invoking qemu helps? It depends on your host-side interface. Using ALSA here, it is generally required. Note that this discussion rather belongs on qemu-devel. Thank you very much. Setting the variable did the trick. Could this perhaps be included in the man page? I am sure there will be others who will eventually run into the same problem as I did. It is a long-standing issue of QEMU that I always wanted to understand but never found the time for. CC'ing malc, maybe he has a good idea how to finally attack this. Attack what exactly? -- mailto:av1...@comtv.ru -- 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: [PATCH 00/13] AMD IOMMU emulation patchset
On Sat, 29 Jan 2011, Eduard - Gabriel Munteanu wrote: Hi everybody, I'm a bit late, I know, school kept me busy. But here it is. I hope I answered your previous concerns in this patchset. Let me know what you think, I hope this gets merged soon. Some testing would be great. The patchset is based on mst/pci. I'll send the SeaBIOS patches soon. Audio bits look fine to me. Cheers, Eduard Eduard - Gabriel Munteanu (13): Generic DMA memory access interface pci: add IOMMU support via the generic DMA layer AMD IOMMU emulation ide: use the DMA memory access interface for PCI IDE controllers rtl8139: use the DMA memory access interface eepro100: use the DMA memory access interface ac97: use the DMA memory access interface es1370: use the DMA memory access interface e1000: use the DMA memory access interface lsi53c895a: use the DMA memory access interface pcnet: use the DMA memory access interface usb-uhci: use the DMA memory access interface usb-ohci: use the DMA memory access interface Makefile.target|2 +- dma-helpers.c | 23 ++- dma.h |4 +- hw/ac97.c |6 +- hw/amd_iommu.c | 694 hw/dma_rw.c| 124 ++ hw/dma_rw.h| 157 hw/e1000.c | 26 ++- hw/eepro100.c | 97 +--- hw/es1370.c|4 +- hw/ide/ahci.c |3 +- hw/ide/internal.h |1 + hw/ide/macio.c |4 +- hw/ide/pci.c | 18 +- hw/lsi53c895a.c| 24 +- hw/pc.c|2 + hw/pci.c |7 + hw/pci.h |7 + hw/pci_ids.h |2 + hw/pci_internals.h |1 + hw/pci_regs.h |1 + hw/pcnet-pci.c |5 +- hw/rtl8139.c | 100 + hw/usb-ohci.c | 54 +++-- hw/usb-uhci.c | 26 +- 25 files changed, 1233 insertions(+), 159 deletions(-) create mode 100644 hw/amd_iommu.c create mode 100644 hw/dma_rw.c create mode 100644 hw/dma_rw.h -- mailto:av1...@comtv.ru -- 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: KVM: High CPU load with audio enabled
On Tue, 9 Nov 2010, Jan Kiszka wrote: Am 09.11.2010 00:48, Michael Tokarev wrote: 08.11.2010 15:40, Stefan Pietsch wrote: Hi, I'm running a Windows XP guest in KVM. After enabling the audio support (-soundhw es1370) the CPU load of the KVM process in the host system goes up to 100%. Tested with: qemu-kvm-0.13.0 Debian 0.13.0+dfsg-1 KVM start command: kvm -m 512 -hda xp.img -soundhw es1370 Did you experience similar problems? Yes, sound in 0.13 appears to be broken. It is looping in select/read loop forever, read returns EAGAIN and select says the filedescriptor is ready. Try to set QEMU_AUDIO_DAC_TRY_POLL=0 for the environment of the qemu process. That's long required to get sound out of the Musicpal emulation as well (malc, you may recall this). It even got worse with current qemu.git: previously, the sounds was just quirky. Now the system is booting way slower in polling mode and is partially not reactive anymore. Wich driver is being used? ALSA stuff should have been fixed by Jindrich Makovicka in: 38cc9b607f85017b095793cab6c129bc9844f441 and 22d948a2d97434192018bdabaf0a50cda7f994be -- mailto:av1...@comtv.ru -- 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] Re: [PATCH] [RFC] Add support for a USB audio device model
On Fri, 10 Sep 2010, H. Peter Anvin wrote: On 09/10/2010 07:47 PM, H. Peter Anvin wrote: On 09/10/2010 06:08 PM, H. Peter Anvin wrote: Any remotely recent stock distro should have support for it. I say should, because I haven't actually tested it with a Linux guest yet. I'll try to do that later; I have to leave now. Just tested it on a stock Fedora 13 64 bit VM; it behaves exactly the same way as under Win7. Sorry but I have no idea what stock Fedora 13 64 bit VM is. Just for the sake of completeness, the Qemu command line was: ~/qemu/git-kvm/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 2 -m 1024 -usb -soundhw usb -hda qemu-fc13-64.img -serial stdio ... and this was with the usb-audio patch applied against top of the the qemu-kvm git tree (the patch applies against the top of the main qemu tree too, but because KVM isn't very stable there it was faster to use the KVM tree.) ^^^ this doesn't parse, somewhere QEMU was replaced by KVM i think Anywho, i tried it with linux-test and custom/minimal compiled 2.6.32 [1] x86_64-softmmu/qemu-system-x86_64 -kernel \ ~/x/bld/linux-2.6.32/arch/x86_64/boot/bzImage -append root=/dev/hda \ -vnc :0 -soundhw usb ~/x/img/linux-0.2.img -usb [-enable-kvm] ^^^ this has no consequence [2] Inside the guest `$ madplay 20thfull.mp2' and things sounded fine with OSS, with ALSA the story is somewhat different, it stuttered for a while but then settled and things went back to smooth playback. So i need a reproduction scenario [1] .config available on request [2] Well actually it has - on the speed `-enable-kvm' makes boot sluggish for whatever reason -- mailto:av1...@comtv.ru -- 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: [PATCH] [RFC] Add support for a USB audio device model
On Fri, 10 Sep 2010, H. Peter Anvin wrote: I discovered that none of the audio device models supported by current Qemu/KVM appear to be supported out of the box on Win7 64 bit (AC97 works fine on 32 bit). The most logical ways to fix that would be to add a long-term supportable audio device model. Intel HD Audio and USB Audio seemed like the most reasonable options, but I opted for USB Audio for a few reasons: I'll look at it tomorow, in the meantime it would be great to know how to test it (i.e. how to build the kernel which includes the driver for this thing) Oh and is the audio output bad when using linux guest too? (I don't have any windows guests to test this part of the equation) P.S. The patches have lot's of tabs in them btw. P.P.S. There's an extension to your Intel HDA Audio option: to get the HDA code from VirtualBox and port it to QEMU. [..snip..] -- mailto:av1...@comtv.ru -- 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 7/7] ac97: use the PCI memory access interface
On Sun, 15 Aug 2010, Eduard - Gabriel Munteanu wrote: This allows the device to work properly with an emulated IOMMU. Fine with me. [..snip..] -- mailto:av1...@comtv.ru -- 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] loader: pad kernel size when loaded from a uImage
On Thu, 29 Jul 2010, Hollis Blanchard wrote: The kernel's BSS size is lost by mkimage, which only considers file size. As a result, loading other blobs (e.g. device tree, initrd) immediately after the kernel location can result in them being zeroed by the kernel's BSS initialization code. Signed-off-by: Hollis Blanchard hol...@penguinppc.org --- hw/loader.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/hw/loader.c b/hw/loader.c index 79a6f95..35bc25a 100644 --- a/hw/loader.c +++ b/hw/loader.c @@ -507,6 +507,13 @@ int load_uimage(const char *filename, target_phys_addr_t *ep, ret = hdr-ih_size; + /* The kernel's BSS size is lost by mkimage, which only considers file + * size. We don't know how big it is, but we do know we can't place + * anything immediately after the kernel. The padding seems like it should + * be proportional to overall file size, but we also make sure it's at + * least 4-byte aligned. */ + ret += (hdr-ih_size / 16) ~0x3; + This portion uses tabs. out: if (data) qemu_free(data); -- mailto:av1...@comtv.ru -- To unsubscribe from this list: send the line unsubscribe kvm-ppc 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] [RFC PATCH 1/7] Generic IOMMU layer
On Wed, 14 Jul 2010, Eduard - Gabriel Munteanu wrote: This provides an API for abstracting IOMMU functions. Hardware emulation code can use it to request address translation and access checking. In the absence of an emulated IOMMU, no translation/checking happens and I/O goes through as before. IOMMU emulation code must provide implementation-specific hooks for this layer. [..snip..] +int __iommu_rw(struct iommu *iommu, + DeviceState *dev, + target_phys_addr_t addr, + uint8_t *buf, + int len, + int is_write) Do not use leading double underscore. [..snip..] -- mailto:av1...@comtv.ru -- 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] [RFC PATCH 7/7] ac97: IOMMU support
On Wed, 14 Jul 2010, Eduard - Gabriel Munteanu wrote: Memory accesses must go through the IOMMU layer. Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro --- hw/ac97.c | 20 +--- 1 files changed, 17 insertions(+), 3 deletions(-) Fine with me. [..snip..] -- mailto:av1...@comtv.ru -- 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] Re: [PATCH v3 1/1] Shared memory uio_pci driver
On Sun, 28 Mar 2010, Jamie Lokier wrote: Avi Kivity wrote: ioctls encode the buffer size into the ioctl number, so in theory strace doesn't need to be taught about an ioctl to show its buffer. Unfortunately ioctl numbers don't always follow that rule :-( It's not a rule to begin with, since there's no way to enforce it. But maybe that's just awful proprietary drivers that I've seen. Anyway, strace should be taught how to read kernel headers to get ioctl types ;-) -- Jamie -- mailto:av1...@comtv.ru -- 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] Inter-VM shared memory PCI device
On Thu, 11 Mar 2010, Nick Piggin wrote: On Thu, Mar 11, 2010 at 03:10:47AM +, Jamie Lokier wrote: Paul Brook wrote: In a cross environment that becomes extremely hairy. For example the x86 architecture effectively has an implicit write barrier before every store, and an implicit read barrier before every load. Btw, x86 doesn't have any implicit barriers due to ordinary loads. Only stores and atomics have implicit barriers, afaik. As of March 2009[1] Intel guarantees that memory reads occur in order (they may only be reordered relative to writes). It appears AMD do not provide this guarantee, which could be an interesting problem for heterogeneous migration.. (Summary: At least on AMD64, it does too, for normal accesses to naturally aligned addresses in write-back cacheable memory.) Oh, that's interesting. Way back when I guess we knew writes were in order and it wasn't explicit that reads were, hence smp_rmb() using a locked atomic. Here is a post by Nick Piggin from 2007 with links to Intel _and_ AMD documents asserting that reads to cacheable memory are in program order: http://lkml.org/lkml/2007/9/28/212 Subject: [patch] x86: improved memory barrier implementation Links to documents: http://developer.intel.com/products/processor/manuals/318147.pdf http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf The Intel link doesn't work any more, but the AMD one does. It might have been merged into their development manual now. It was (http://www.intel.com/products/processor/manuals/): Intel╝ 64 Architecture Memory Ordering White Paper This document has been merged into Volume 3A of Intel 64 and IA-32 Architectures Software Developer's Manual. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] Re: Question about KVM and PC speaker
On Thu, 14 May 2009, Sebastian Herbszt wrote: malc wrote: On Wed, 13 May 2009, Sebastian Herbszt wrote: Jan Kiszka wrote: Moreover, does sound work at all with your qemu? The image I tried [1] issues two beeps after loading (obviously via direct hw access) - a good way to check general support. Note that one reason for broken host sound with qemu can be OSS. For that reason I always configure my qemu with --audio-drv-list=alsa. Thats a good hint :) Seems i used to compile qemu without --audio-drv-list. Since dsound and fmod drivers don't compile here (i likely miss some libs in my mingw), i used sdl. Don't do that. Here's a nice tutorial Kazu made that will probably help you: http://www.h7.dion.ne.jp/~qemu-win/Audio-en.html So you're saying the use of sdl for audio is not recommended? Yes. Now i can hear those two beeps with the image you suggested. Tho those are coming thru my sound card and not the hosts pc speaker (even with -soundhw pcspk, but maybe that option means something different). And it will always come through your soundcard. pcspk is not a passthrough thing. Thanks for the clarification. With INT 10h AH=0Eh i now can hear a beep too, but it doesn't stop and qemu somewhat freezes. Huh? With this INT 10h function qemu should beep once, but it does loop the beep infinitely. Normally i can exit qemu by clicking on the [x] window close icon, but while it does endlessly beep that doesn't work (vista says process doesn't respond). Using quit in the monitor window doesn't work either. Can you post some .com file sparing me from writing the code for one myself? -- mailto:av1...@comtv.ru -- 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] Re: Question about KVM and PC speaker
On Wed, 13 May 2009, Sebastian Herbszt wrote: Jan Kiszka wrote: Sebastian Herbszt wrote: With the modified vgabios (see below) it does beep on bochs on vista, but not on qemu. Works fine for me! Did you check twice that your modified vgabios is actually loaded by qemu (e.g. via strace)? Yes, it uses the right rom. Moreover, does sound work at all with your qemu? The image I tried [1] issues two beeps after loading (obviously via direct hw access) - a good way to check general support. Note that one reason for broken host sound with qemu can be OSS. For that reason I always configure my qemu with --audio-drv-list=alsa. Thats a good hint :) Seems i used to compile qemu without --audio-drv-list. Since dsound and fmod drivers don't compile here (i likely miss some libs in my mingw), i used sdl. Don't do that. Here's a nice tutorial Kazu made that will probably help you: http://www.h7.dion.ne.jp/~qemu-win/Audio-en.html Now i can hear those two beeps with the image you suggested. Tho those are coming thru my sound card and not the hosts pc speaker (even with -soundhw pcspk, but maybe that option means something different). And it will always come through your soundcard. pcspk is not a passthrough thing. With INT 10h AH=0Eh i now can hear a beep too, but it doesn't stop and qemu somewhat freezes. Huh? Jan PS: Your patch was mangled by your mail client. Fortunately, it was small enough for manual fixing. Unfortunatelly Windows Mail tends to do this and i failed to find an option to fix it. - Sebastian -- mailto:av1...@comtv.ru -- 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] Re: [PATCH v2 4/8] qemu:virtio-net: Add a virtqueue for control commands from the guest
On Wed, 4 Feb 2009, Alex Williamson wrote:
[..snip..]
+static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
+{
+struct virtio_net_ctrl_hdr ctrl;
+virtio_net_ctrl_ack status = VIRTIO_NET_ERR;
+VirtQueueElement elem;
+
+while (virtqueue_pop(vq, elem)) {
+if ((elem.in_num 1) | (elem.out_num 1)) {
^ intended ?
[..snip..]
--
mailto:av1...@comtv.ru
--
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 v2 6/8] qemu:virtio-net: Enable filtering based on MAC, promisc, broadcast and allmulti
On Tue, 3 Feb 2009, Anthony Liguori wrote:
Blue Swirl wrote:
On 2/3/09, Alex Williamson alex.william...@hp.com wrote:
Make use of the new RX_MODE control virtqueue class by dropping
packets the guest doesn't want to see.
Signed-off-by: Alex Williamson alex.william...@hp.com
+static uint8_t bcast[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
'const'?
It may be good practice but practically speaking, I don't think it will
generate different code. The only thing that uses bcast is memcmp() which
should be a builtin. Since bcast doesn't otherwise escape the function, it's
an obvious candidate for optimization. I think the compiler already has
enough information that const doesn't tell it anything more.
It does generate different code, bcast is being put into rodata in case
of const and data otherwise, whether it makes practical difference for
QEMU is another matter.
--
mailto:av1...@comtv.ru
--
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 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling v2
On Tue, 30 Sep 2008, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt [EMAIL PROTECTED] *update* further debugging according to some requests revealed that ARCH_CFLAGS does not contain all CFLAGS that might be needed, especially those supplied via extra-cflags. Therefore people supplying things via extra-cflags instead of an environment variable might have had issues. This part i don't get, there are few more checks before/after hostlongbits where no CFLAGS are added to the $cc argument list. What makes hostlongbits selection special? Do people specify -m32/-m64 via --extra-cflags? A recent kvm merge with qemu brought code for 64bit power that broke cross compilation. The issue is caused by configure trying to execute target architecture binaries where configure is executed. Yes, i never thought about cross-compilation, my bad. I tried to change that detection so that it works withwithout cross compilation with only a small change and especially without an addtional configure command line switch. Including the bits/wordsize.h header a platform usually can check its wordsize and by doing that configure can check the hostlongbits without executing the binary. Instead it now stops after preprocessing stage which resolved the __WORDSIZE constant and retrieves that value. I don't like my new check style, but it is at least less broken than before. Another approach that was suggested was that qemu might end up needing something like asm-offsets in the kernel to manage architecture sizes etc. Comments and other approaches welcome. I think Hollis Blanchard's method is sound, Thank you for bringing this up. -- mailto:[EMAIL PROTECTED] -- 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
Re: [Qemu-devel] [PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling v2
On Tue, 30 Sep 2008, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt [EMAIL PROTECTED] The commit message of r5364, the revision which basically exists because of your posts, was somehow butchered and as such doesn't include any references, i'm very sorry about that. The above line was there in the commit message editing buffer, but then i somehow screwed it all up, probably when trying to reformat stuff suffling text around. Once again, i'm sorry. [..snip..] -- mailto:[EMAIL PROTECTED] -- 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
Re: [Qemu-devel] [PATCH 2/3] kvm-userspace: kvmppc: fix hostlonbits detection when cross compiling v2
On Tue, 30 Sep 2008, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt [EMAIL PROTECTED] *update* further debugging according to some requests revealed that ARCH_CFLAGS does not contain all CFLAGS that might be needed, especially those supplied via extra-cflags. Therefore people supplying things via extra-cflags instead of an environment variable might have had issues. This part i don't get, there are few more checks before/after hostlongbits where no CFLAGS are added to the $cc argument list. What makes hostlongbits selection special? Do people specify -m32/-m64 via --extra-cflags? A recent kvm merge with qemu brought code for 64bit power that broke cross compilation. The issue is caused by configure trying to execute target architecture binaries where configure is executed. Yes, i never thought about cross-compilation, my bad. I tried to change that detection so that it works withwithout cross compilation with only a small change and especially without an addtional configure command line switch. Including the bits/wordsize.h header a platform usually can check its wordsize and by doing that configure can check the hostlongbits without executing the binary. Instead it now stops after preprocessing stage which resolved the __WORDSIZE constant and retrieves that value. I don't like my new check style, but it is at least less broken than before. Another approach that was suggested was that qemu might end up needing something like asm-offsets in the kernel to manage architecture sizes etc. Comments and other approaches welcome. I think Hollis Blanchard's method is sound, Thank you for bringing this up. -- mailto:[EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
