Hi,
> That was indeed the ISR field. Fixing that makes seabios reach the same point
> as
> legacy virtio before failing.
>
> I don't see the original correspondence about seabios failures you've
> reported, if
> you want to forward them over we can look at it further.
It was a few months
Hi,
> Thanks for testing! I didn't even thing about seabios as a testing target.
Not surprising, support isn't upstream, ran into a bunch of issues[1][2]
last time I tried to combine the two, ran into some issues and nobody
seemed to care, so the seabios patches where just sitting in a branch
On Mi, 2015-11-18 at 00:11 -0500, Sasha Levin wrote:
> This is a first go at adding support for the modern (based on the 1.0 virtio
> spec) virtio-pci implementation.
> To sum it up: this is a lightly tested version for feedback about the design
> and to weed out major bugs people notice.
On Mi, 2015-11-18 at 23:01 -0500, Sasha Levin wrote:
> On 11/18/2015 11:00 PM, Sasha Levin wrote:
> > Anyways, I debugged it for a bit a found that seabios attempts to write to
> > the notification BAR, I look further tomorrow to narrow it down and fix it.
>
> Err, *read*, obviously.
>
> I've
On Fr, 2015-10-16 at 11:48 -0400, Eric S. Johansson wrote:
>
> On 10/16/2015 07:55 AM, Stefan Hajnoczi wrote:
> > QEMU can emulate PCI soundcards, including the Intel HD Audio codec
> > cards (-device intel-hda or -soundhw hda might do the trick). Low
> > latency and power consumption are
On Mi, 2015-09-16 at 07:23 +0200, Jan Kiszka wrote:
> On 2015-09-15 23:19, Alex Williamson wrote:
> > On Mon, 2015-04-13 at 02:32 +0300, Nadav Amit wrote:
> >> Due to old Seabios bug, QEMU reenable LINT0 after reset. This bug is long
> >> gone
> >> and therefore this hack is no longer needed.
Hi,
AndroidPipe is a communication channel between the guest system and
the emulator itself. Guest side device node can be opened by multi
processes at the same time with different service name. It has a
de-multiplexer on the QEMU side to figure out which service the guest
actually wanted,
FIXME. No idea how to figure how much ram we have.
For now claim we have 128 MB. That is the minimum kvmtool uses
if you don't specify something via -m (if I read the code correctly).
So things should at least work, even though we might leave memory
unused.
Signed-off-by: Gerd Hoffmann kra
Add CONFIG_KVMTOOL, some initial preparations so seabios
at least prints some debug messages on the serial line.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
Makefile| 1 +
src/Kconfig | 7 +++
src/post.c | 2 +-
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git
seabios uses the serial line one-way.
Only debug output, no keyboard input.
So the boot menu is pointless, you can't
pick something anyway. So turn it off.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
src/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/Kconfig b/src
.
Not yet debugged who is at fault here.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
src/hw/virtio-ring.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/hw/virtio-ring.h b/src/hw/virtio-ring.h
index 7df9004..3a143e0 100644
--- a/src/hw/virtio-ring.h
+++ b/src/hw
for the root filesystem to
show up and drops into the emergency shell, where you can play around a
bit.
enjoy,
Gerd
Patches also available in the git repository at:
git://git.kraxel.org/seabios kvmtool
Gerd Hoffmann (7):
kvmtool
Hmm. Doesn't match virtio spec.
But easy to check and handle.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
src/hw/virtio-pci.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/hw/virtio-pci.c b/src/hw/virtio-pci.c
index 6df5194..465deb9 100644
--- a/src
Disable stuff not emulated by kvmtool, no need
to waste time and code for that.
Enable virtio-blk and virtio-scsi.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
src/Kconfig | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/Kconfig b/src/Kconfig
index
Make a pci bus scan, so we find the virtio devices.
Tested with virtio-blk only (kvmtool uses that by default).
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
src/fw/paravirt.c | 9 +
src/fw/paravirt.h | 1 +
src/post.c| 1 +
3 files changed, 11 insertions(+)
diff --git
On Fr, 2015-05-22 at 12:21 +0100, Peter Maydell wrote:
On 22 May 2015 at 12:12, Daniel P. Berrange berra...@redhat.com wrote:
Yep, it is hard saying no - but I'd think as long as it was possible to add
the extra features using -device, it ought to be practical to keep a virt
machine types
Hi,
qboot is available at git://github.com/bonzini/qboot.git.
Firmware repo has packages now.
https://www.kraxel.org/repos/firmware.repo
https://www.kraxel.org/repos/jenkins/qboot/
enjoy,
Gerd
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
On Mo, 2015-03-16 at 14:16 -0400, Bandan Das wrote:
Jan Kiszka jan.kis...@siemens.com writes:
Am 2015-03-12 um 09:11 schrieb Gerd Hoffmann:
On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote:
Hi,
apparently since the latest QEMU updates I'm getting this once in a
while:
http
On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote:
Hi,
apparently since the latest QEMU updates I'm getting this once in a
while:
http://www.seabios.org/pipermail/seabios/2015-March/008897.html
cheers,
Gerd
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of
On Do, 2015-03-12 at 09:14 +0100, Jan Kiszka wrote:
Am 2015-03-12 um 09:11 schrieb Gerd Hoffmann:
On Do, 2015-03-12 at 09:09 +0100, Jan Kiszka wrote:
Hi,
apparently since the latest QEMU updates I'm getting this once in a
while:
http://www.seabios.org/pipermail/seabios/2015-March
On Sa, 2014-12-06 at 12:17 +0800, Jike Song wrote:
On 12/05/2014 04:50 PM, Gerd Hoffmann wrote:
A few comments on the kernel stuff (brief look so far, also
compile-tested only, intel gfx on my test machine is too old).
* Noticed the kernel bits don't even compile when configured
Hi,
In KVMGT, we need to register an iodev only *after* BAR
registers are
written by guest.
Oh, the guest can write the bar register at any time. Typically it
happens at boot only, but it can also happen at runtime, for example on
reboot.
I've also seen the
Hi,
I pass throught the usb audio device (logitech h800 USB 046d:0a29) and
it is seen as a device in windows. then I hear the headset sync-up
beeps and the device vanishes from windows. pointers as to what I
should look at next?
Adding back Hans and Gerd...
Eric are you using
Hi,
(XEN)
(XEN) Panic on CPU 0:
(XEN) IO-APIC + timer doesn't work! Boot with apic_verbosity=debug and
send a report. Then try booting with the 'noapic' option
(XEN)
Just tried the same a few days
1. I plug in the phone and do an lsusb:
Bus 003 Device 03: ID 04e8:6860 Samsung Electronics Co., Ltd GT-I9100
Phone [Galaxy S II], GT-I9300 Phone [Galaxy S III], GT-P7500 [Galaxy Tab
10.1] , GT-I9500 [Galaxy S 4]
2. I create the proper configuration in my qemu command line:
-usb -device
On Sa, 2014-04-26 at 13:02 +0200, Paolo Bonzini wrote:
Il 26/04/2014 11:40, Paolo Bonzini ha scritto:
Il 25/04/2014 09:39, Gerd Hoffmann ha scritto:
Anyone has plans to add smm support to kvm?
No plans, but it should be a Simple Matter Of Programming...
Well, we need:
- an extra
Hi,
Anyone has plans to add smm support to kvm?
We have two potential use cases meanwhile:
(1) OVMF could use it to implement the LockBox (storage area the
OS can't tamper with, needed to make secure boot actually secure).
(2) SeaBIOS considers using a SMM trampoline to switch into
Hi,
I synced to hkp://pgp.mit.edu.
Key ID: 81AB73C8
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x9CA4ABB381AB73C8
I think the key servers sync to each other anyway,
so it doesn't matter much which one you pick.
cheers,
Gerd
--
To unsubscribe from this list: send the line
On 06/06/13 08:34, Gleb Natapov wrote:
On Wed, Jun 05, 2013 at 07:41:17PM -0500, Anthony Liguori wrote:
Oh, you mean in real mode.
SeaBIOS runs the virtio code in 32-bit mode with a flat memory layout.
There are loads of ASSERT32FLAT()s in the code to make sure of this.
Well, not exactly.
Hi,
For seabios itself this isn't a big issue, see pci_{readl,writel} in
src/pci.c. When called in 16bit mode it goes into 32bit mode
temporarily, just for accessing the mmio register. ahci driver uses it,
xhci driver (wip atm) will use that too, and virtio-{blk,scsi} drivers
in seabios
On 06/01/13 01:01, Jordan Justen wrote:
On Fri, May 31, 2013 at 2:32 AM, Gerd Hoffmann kra...@redhat.com wrote:
Hi,
I guess -bios would load coreboot. Coreboot would siphon the data
necessary for ACPI table building through the current (same) fw_cfg
bottleneck, build the tables,
Yes
Hi,
I guess -bios would load coreboot. Coreboot would siphon the data
necessary for ACPI table building through the current (same) fw_cfg
bottleneck, build the tables,
Yes.
load the boot firmware (SeaBIOS or OVMF or
something else -- not sure how to configure that),
The coreboot rom has
On 05/31/13 10:13, Peter Stuge wrote:
Kevin O'Connor wrote:
one possible way forward would be to split the current SeaBIOS rom
into two roms: qvmloader and seabios. The qvmloader would do
the qemu specific platform init (pci init, smm init, mtrr init, bios
tables) and then load and run the
Hi,
Raised
that QOM interface should be sufficient.
Agree on this one. Ideally the acpi table generation code should be
able to gather all information it needs from the qom tree, so it can be
a standalone C file instead of being scattered over all qemu.
Ack. So my basic argument is
Hi,
Why should this be true? Shouldn't we be allowed to increase the amount
of memory the guest has across reboots? That's equivalent to adding
another DIMM after power off.
poweroff is equivalent to exiting qemu, not to guest reset.
Not generating tables on reset does limit what we can
On 05/29/13 01:53, Kevin O'Connor wrote:
On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
Juan is not available now, and Anthony asked for
agenda to be sent early.
So here comes:
Agenda for the meeting Tue, May 28:
- Generating acpi tables
I didn't see any meeting
Hi,
possible complexity of having to regenerate
tables on a vm reboot,
Why tables should be regenerated at reboot? I remember hotplug being
mentioned in the call. Hmm? Which hotplugged component needs acpi
table updates to work properly? And what is the point of hotplugging if
you
On 04/11/13 11:29, Stefan Hajnoczi wrote:
On Mon, Apr 08, 2013 at 12:27:06PM +, Zhanghaoyu (A) wrote:
On Sun, Apr 07, 2013 at 04:58:07AM +, Zhanghaoyu (A) wrote:
I start a kvm VM with vnc(using the zrle protocol) connect, sometimes
qemu program crashed during starting period, received
On 04/08/13 17:11, Peter Maydell wrote:
On 6 April 2013 00:52, Sriram Murthy srira...@yahoo.com wrote:
(actually, the virtualbox SVGA card is based off of the KVM VGA card)
Is it possible to implement it as an extension to the VGA
card device, or has it diverged incompatibly such that it
Hi,
Gerd: Are you willing to co-maintain the QEMU buildmaster with Daniel
and Christian? It would be awesome if you could do this given your
experience running and customizing buildbot.
I'll try to set aside some time for that. Christians idea to host the
config at github is good, that
Hi,
hw/qxl.c:portio_list_add(qxl_vga_port_list,
pci_address_space_io(dev), 0x3b0);
hw/vga.c:portio_list_add(vga_port_list, address_space_io, 0x3b0);
That reminds me I should solve this in a more elegant way.
qxl takes over the vga io ports. The reason it does this is because
On 11/09/12 13:23, Veruca Salt wrote:
I'm pretty sure the answer to this is 'no', but does the ehci implementation
support USB-connected USB hubs?
Or will that come out in 1.2 in the xhci implementation.
No. You can try using the emulated hub and hook up the devices
connected to the hub
Hi,
I just want to enable 64 bit bars for KVM usage, seabios 1.7.0 is
used in current qemu-kvm, which not handle 64 bit bars yet. I cloned
seabios code from kernel.org(seems no 64 bit bars supporting), but I
was not taking notice of the tree on http://git.qemu.org/, yes it has
already done
On 11/02/12 06:42, Xudong Hao wrote:
64 bit bar sizing and MMIO allocation. The 64 bit window is placed above high
memory, top down from the end of guest physical address space.
What problem you are trying to fix? The existing code should handle
64bit bars just fine. By default they are
Hi,
I think deferring IRQ events to the point when the complete vmstate is
loaded is the cleaner and more robust approach.
Agree. Just schedule a bh in post_load.
See also a229c0535bd336efaec786dd6e352a54e0a8187d
cheers,
Gerd
--
To unsubscribe from this list: send the line unsubscribe
On 11/02/12 16:13, Paolo Bonzini wrote:
Hi,
I think deferring IRQ events to the point when the complete vmstate
is
loaded is the cleaner and more robust approach.
Agree. Just schedule a bh in post_load.
See also a229c0535bd336efaec786dd6e352a54e0a8187d
No, it cannot a bh. Right now
Hi,
Well, we also want to clean up the registers, so how about:
BAR0: legacy, as is. If you access this, don't use the others.
Ok.
BAR1: new format virtio-pci layout. If you use this, don't use BAR0.
BAR2: virtio-cfg. If you use this, don't use BAR0.
Why use two bars for this? You
Hi,
Why use two bars for this? You can put them into one mmio bar, together
with the msi-x vector table and PBA. Of course a pci capability
describing the location is helpful for that ;)
You don't need a capability. You can also just add a config offset
field to the register set and
Hi,
But I think we could solve this in a different way. I think we could
just move the virtio configuration space to BAR1 by using a transport
feature bit.
Why hard-code stuff?
I think it makes alot of sense to have a capability simliar to msi-x
which simply specifies bar and offset of
Hi,
So we could have for virtio something like this:
Capabilities: [??] virtio-regs:
legacy: BAR=0 offset=0
virtio-pci: BAR=1 offset=1000
virtio-cfg: BAR=1 offset=1800
This would be a vendor specific PCI capability so lspci
order. Better to make it explicit.
Like the attached incremental patch?
cheers,
Gerd
From d46b14dfd74dcc37fe187dc76cd681ad7dbff2d5 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann kra...@redhat.com
Date: Wed, 19 Sep 2012 13:31:04 +0200
Subject: [PATCH] [fixup] vga mmio
Signed-off-by: Gerd
Hi,
+vbe_ioport_write_index(d-vga, 0, index);
+return vbe_ioport_read_data(d-vga, 0);
These functions are only available with CONFIG_BOCHS_VBE #defined, so
this code should be conditional as well.
But building without CONFIG_BOCHS_VBE is not very useful since it's
used by the
This patch adds a mmio bar to the qemu standard vga which allows to
access the standard vga registers and bochs dispi interface registers
via mmio.
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/vga-pci.c | 97
On 09/18/12 12:32, Benjamin Herrenschmidt wrote:
On Tue, 2012-09-18 at 11:51 +0200, Gerd Hoffmann wrote:
This patch adds a mmio bar to the qemu standard vga which allows to
access the standard vga registers and bochs dispi interface registers
via mmio.
I had a patch like that somewhere
Hi,
- Apply the patches at the end of this mail to kvm and SeaBIOS to
allow for more BAR space under 4G. (The relevant BARs on the
graphics cards _are_ 64 bit BARs, but kvm seemed to turn those
into 32 bit BARs in the guest.)
Which qemu/seabios versions have you used?
qemu-1.2 (+
On 09/06/12 01:28, Kevin O'Connor wrote:
On Wed, Sep 05, 2012 at 07:28:15AM +0200, Gerd Hoffmann wrote:
This patch makes seabios use the acpi pmtimer instead of tsc for
timekeeping. The pmtimer has a fixed frequency and doesn't need
calibration, thus it doesn't suffer from calibration errors
Hi,
+u32 pmtimer = inl(ioport);
+return (u64)wraps 24 | pmtimer;
BTW, why is this 24, and if it should be that way, shouldn't the
pmtimer be inl(ioport) 0xff ?
The pmtimer is defined to be 24 bits wide, so the shift is correct.
This is not true in general. It can be either
On 09/02/12 22:42, Kevin O'Connor wrote:
On Tue, Aug 14, 2012 at 07:29:19AM +0200, Gerd Hoffmann wrote:
This patch makes seabios use the acpi pmtimer instead of tsc for
timekeeping. The pmtimer has a fixed frequency and doesn't need
calibration, thus it doesn't suffer from calibration errors
This patch makes seabios use the acpi pmtimer instead of tsc for
timekeeping. The pmtimer has a fixed frequency and doesn't need
calibration, thus it doesn't suffer from calibration errors due to a
loaded host machine.
[ v3: mask port ioport read ]
[ v2: add CONFIG_PMTIMER ]
Signed-off-by: Gerd
Hi,
Isnt pmtimer ioport usable? 14MHz.
Can give it a try. 14 MHz looks wrong though, apci.h says:
/* PM Timer ticks per second (HZ) */
#define PM_TIMER_FREQUENCY 3579545
Is this fixed? Or hardware specific?
cheers,
Gerd
--
To unsubscribe from this list: send the line unsubscribe kvm
This patch makes seabios use the acpi pmtimer instead of tsc for
timekeeping. The pmtimer has a fixed frequency and doesn't need
calibration, thus it doesn't suffer from calibration errors due to a
loaded host machine.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
src/clock.c | 29
This patch makes seabios use the acpi pmtimer instead of tsc for
timekeeping. The pmtimer has a fixed frequency and doesn't need
calibration, thus it doesn't suffer from calibration errors due to a
loaded host machine.
[ v2: add CONFIG_PMTIMER ]
Signed-off-by: Gerd Hoffmann kra...@redhat.com
calculations.
Draft patch attached. Comments?
cheers,
Gerd
From e42d62e90ae4b8a00413a0665d4022069154a516 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann kra...@redhat.com
Date: Thu, 9 Aug 2012 13:26:18 +0200
Subject: [PATCH] kvmclock clocksource
Signed-off-by: Gerd Hoffmann kra...@redhat.com
in turn leads to disk I/O errors due to timeouts, especially
as I/O requests tend to take a bit longer than usual on a loaded box ...
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
src/clock.c|9 +
src/paravirt.c | 90
src
Hi,
+u64 kvm_tsc_khz(void)
+{
+u32 eax, ebx, ecx, edx, msr;
+struct pvclock_vcpu_time_info time;
+u32 addr = (u32)(time);
+u64 khz;
+
+/* check presence and figure msr number */
+cpuid(KVM_CPUID_FEATURES, eax, ebx, ecx, edx);
+if (eax
Hi,
er, the documentation says 4 bytes (so stack alignment works). I
distinctly remember having a large alignment requirement so we don't
cross a page or slot boundary... something's wrong here.
case MSR_KVM_SYSTEM_TIME: {
[ ... ]
So your tests worked by pure luck, but the bug is
Hi,
So what do you suggest? The options I see are:
(1) Use this patch (with alignment issue fixed of course).
(2) Do a full kvmclock implementation. Feels a bit like overkill.
(3) SeaBIOS can fallback to the PIT for timing on machines which
have no TSC. We could do that too
On 07/11/12 18:45, Vasilis Liaskovitis wrote:
Hi,
On Wed, Jul 11, 2012 at 01:56:19PM +0200, Gerd Hoffmann wrote:
On 07/11/12 12:31, Vasilis Liaskovitis wrote:
In order to hotplug memory between RamSize and BUILD_PCIMEM_START, the pci
window needs to start at BUILD_PCIMEM_START (0xe000
On 07/11/12 12:31, Vasilis Liaskovitis wrote:
In order to hotplug memory between RamSize and BUILD_PCIMEM_START, the pci
window needs to start at BUILD_PCIMEM_START (0xe000).
Otherwise, the guest cannot online new dimms at those ranges due to pci_root
window conflicts. (workaround for
On 07/06/12 16:53, Hans de Goede wrote:
Commit 0f588df8b3688b00e77aabaa32e26ece5f19bd39, added code
to ehci_wakeup to kick the async schedule on wakeup, but the else
was positioned wrong making it trigger for devices which are routed
to the companion rather then to the ehci controller itself.
On 07/06/12 12:09, Hans de Goede wrote:
Here are USB 2 bug-fixes, please also cherry-pick these into the
stable-1.1 branch, esp. the second one as that fixes an easily triggerable
assert.
Note these patches are against 1.1.0, not against master, but they are
relevant
for, and should apply
On 05/28/12 11:30, Avi Kivity wrote:
On 05/25/2012 11:36 AM, Veruca Salt wrote:
Avi- would love to test out 1.1, as we are currently using the ehci method
which has been frozen at 'experimental' for so long.
Is there any user documentation on the xhci methods?
Copying qemu-devel, where
video memory (1 MB is minimum) for textmode-only guests or qemu
scalability tests.
Comments?
cheers,
Gerd
Gerd Hoffmann (2):
vga: raise xres+yres limits
vga: make vram size configurable
hw/cirrus_vga.c |8 ++--
hw/qxl.c|5 -
hw/vga-isa.c|8 +++-
hw/vga
are not growing that fast.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/vga_int.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/vga_int.h b/hw/vga_int.h
index 7685b2b..297c2f1 100644
--- a/hw/vga_int.h
+++ b/hw/vga_int.h
@@ -31,8 +31,8 @@
/* bochs VBE support
real
hardware.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/cirrus_vga.c |8 ++--
hw/qxl.c|5 -
hw/vga-isa.c|8 +++-
hw/vga-pci.c|8 +++-
hw/vga.c| 13 ++---
hw/vga_int.h|4 ++--
hw/vmware_vga.c | 13
Hi,
As a workaround you can use -vga std or -vga qxl. The latter will work
even better when we have a kernel driver.
There is a kernel driver for -vga std too ;)
http://patchwork.ozlabs.org/patch/145479/
Didn't try on ppc though. There is a funky #ifdef TARGET_I386 in
vbe_portio_list[],
Hi,
As a workaround you can use -vga std or -vga qxl. The latter will work
even better when we have a kernel driver.
There is a kernel driver for -vga std too ;)
http://patchwork.ozlabs.org/patch/145479/
Didn't try on ppc though. There is a funky #ifdef TARGET_I386 in
vbe_portio_list[],
On 03/27/12 17:48, Jaap Winius wrote:
Hi folks,
Recently I learned how to configure KVM with USB pass-though
functionality. In my case I configured my guest domain with this block
of code:
hostdev mode='subsystem' type='usb' managed='yes'
source
vendor id='0x0c93'/
diff --git a/src/ssdt-pcihp.dsl b/src/ssdt-pcihp.dsl
index 442e7a8..3f50169 100644
--- a/src/ssdt-pcihp.dsl
+++ b/src/ssdt-pcihp.dsl
@@ -24,6 +24,7 @@ DefinitionBlock (ssdt-pcihp.aml, SSDT, 0x01, BXPC,
BXSSDTPCIHP, 0x1)
ACPI_EXTRACT_METHOD_STRING aml_ej0_name \
On 02/24/12 19:54, Pekka Enberg wrote:
Hi,
I played around with the --debug-ioport command line option and was able
to cheat my way past SeaBIOS POST phase. Should SeaBIOS automatically pick
up virtio devices and attempt to boot them?
Yes, it can handle virtio-blk (and soon virtio-scsi
Hi,
So looking at SeaBIOS code, it seems to me we could simply make LKVM
lie to it by claiming to be coreboot and get away with it, no? We'd
basically avoid all the PCI allocation passes and such.
I doubt this is going to fly if you want seabios boot from a
virtio-blk-pci device ...
On 02/20/12 23:52, Michael S. Tsirkin wrote:
Here's a new version of the patch.
TODOs:
- windows guest testing
Changes from v2:
- added slot id capability
- migration support
- misc fixes
- fix checkpatch errors
64bit prefetch memory window works now:
00:10.0 PCI bridge: Red Hat,
Hi,
This seems to not support 64bit prefetchable memory windows, at least
linux doesn't think it does, lspci looks like this:
00:10.0 PCI bridge: Red Hat, Inc. Device 0001 (prog-if 00 [Normal decode])
[ ... ]
Memory behind bridge: f600-f60f
Prefetchable memory
On 02/13/12 10:15, Michael S. Tsirkin wrote:
TODO:
- migration support
- fix dependency on pci_internals.h
fix checkpatch warnings
cheers,
Gerd
--
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
Hi,
+/* If we don't specify the name, the bus will be addressed as id.0,
where
+ * id is the parent id. But it seems more natural to address the bus
using
+ * the parent device name. */
+if (dev-qdev.id *dev-qdev.id) {
+br-bus_name = dev-qdev.id;
+}
That
On 02/13/12 10:16, Michael S. Tsirkin wrote:
This adds support for a standard pci to pci bridge,
enabling support for more than 32 PCI devices in the system.
Device hotplug is supported by means of SHPC controller.
For guests with an SHPC driver, this allows robust hotplug
and even hotplug of
Hi,
Now, I've a question: what seabios implementation of extboot we're
talking about?
seabios boots natively from virtio now, so for that use case extboot
isn't needed any more.
-option-rom which is impossible to select as a first
boot device?
'qemu-kvm -option-rom
a22fe41d90d484a68317e0ac46785611afab545f
Author: Gerd Hoffmann kra...@redhat.com
Date: Mon Jun 14 12:28:23 2010 +0200
Fix vnc memory corruption with width = 1400
vnc assumes that the screen width is a multiple of 16 in several places.
If this is not the case vnc will overrun buffers
Hi,
I noticed that there's a directory, kvm/vgabios, in the distribution
which appears to have source code for the relevant targets. Indeed,
one of the source files there, vbetables-gen.c, seems to be the one
I need to modify to add my new display resolutions. Great.
So naturally, I
On 11/22/11 01:25, Anthony Liguori wrote:
Due to this commit:
commit 40d6444e91c6ab17e5e8ab01d4eece90cbc4afed
Author: Avi Kivity a...@redhat.com
Date: Tue Nov 15 20:12:17 2011 +0200
configure: build position independent executables on x86-Linux hosts
PIE binaries cannot be linked
Hi,
As far I know it is pretty much impossible to figure the
foreground/background colors of the terminal you are running on. You
Glad to hear that, I thought I hadn't researched that much (I did). Hope
somebody appears and tell us how it is done :-)
In xterm, '\e]10;?\e\\' and
Hi,
What we want to have is to have a set of distinctive colors - just
two (background, foreground) colors are not enough - we also need
colors to highlight certain information - we need 5-6 colors for the
output to be maximally expressive. Is there a canonical way to handle
that while
Hi,
Plus allowing full .perfconfig configurability of all the relevant
colors, for those with special taste.
Sure. Maybe also allow multiple color sections and pick them by $TERM
or --colors switch, i.e. [colors xterm].
Its fully configurable as of now, what we need is a set of
On 11/07/11 17:00, Anthony Liguori wrote:
On 11/07/2011 09:33 AM, Gerd Hoffmann wrote:
This patch removes the code lines which set the subsystem id for the
emulated ac97 card to 8086:. Due to the device id being zero the
subsystem id isn't vaild anyway. With the patch applied the sound
Hi,
Wouldn't it be better to have the subsystem vendor and device id be
configurable, set the default to the qemu subsystem ids, and then set it
to 8086: for 1.0?
I don't want this being fully configurable just for the snake of
backward compatibility with old qemu versions.
I
Hi,
Indeed, documentation is lacking, I think coming from a kernel
standpoint I relied too much in the documentation is source code
mantra of old days.
Sorry for the shameless plug, but as you are speaking of lacking
documentation: Where the heck is the perf config file documented, other
Hi,
documentation: Where the heck is the perf config file documented, other
than source code? Reading the parser to figure how the config file is
supposed to look like really isn't fun :(
I'm looking for a way to disable the colors in the perf report tui. Or
configure them into
Hi,
Agreed. If we can know the virtual device for KVM in a better way
(e.g. any specific PCI SSID or such), we can narrow the condition more
safely.
PCI Subsystem ID 1af4:1100 is qemu/kvm (not only Intel HDA, most other
emulated pci devices have it too). Complete entry:
00:04.0 0403:
Hi,
Usable - I've tried kvm-tool several times and still (today) fail to
get a standard SUSE image (with a kernel I have to compile and provide
separately...) up and running *). Likely a user mistake, but none that
is very obvious. At least to me.
Same here.
No support for booting from
Hi,
It's not just about code, it's as much about culture and development process.
Indeed. The BSDs have both kernel and the base system in a single
repository. There are probably good reasons for (and against) it.
In Linux we don't have that culture. No tool (except perf) lives in the
1 - 100 of 284 matches
Mail list logo
