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 bac
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 nev
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 i
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. Feedback
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 usuall
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. Sin
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 wan
.
Not yet debugged who is at fault here.
Signed-off-by: Gerd Hoffmann
---
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/virtio-ring.h
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
---
src/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/Kconfig b/src/Kconfig
dracut decides to not wait any longer 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
----
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
---
src/fw/paravirt.c | 9 +
src/fw/paravirt.h | 1 +
src/post.c| 1 +
3 files changed, 11 insertions(+)
diff --git a/src/fw/paravirt.c b
Hmm. Doesn't match virtio spec.
But easy to check and handle.
Signed-off-by: Gerd Hoffmann
---
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/hw/virtio-
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
---
src/Kconfig | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/Kconfig b/src/Kconfig
index 7620067..2bb90c0
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 Hof
Add CONFIG_KVMTOOL, some initial preparations so seabios
at least prints some debug messages on the serial line.
Signed-off-by: Gerd Hoffmann
---
Makefile| 1 +
src/Kconfig | 7 +++
src/post.c | 2 +-
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
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 Fr, 2015-05-22 at 12:21 +0100, Peter Maydell wrote:
> On 22 May 2015 at 12:12, Daniel P. Berrange 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 "-nodefaults
On Mo, 2015-03-16 at 14:16 -0400, Bandan Das wrote:
> Jan Kiszka 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 l
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
> >>
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 bod
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 b
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...
>
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
> 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 -dev
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 Pro
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 32b
Hi,
> I synced to hkp://pgp.mit.edu.
>
> Key ID: 81AB73C8
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=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 "u
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
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,
On 06/01/13 01:01, Jordan Justen wrote:
> On Fri, May 31, 2013 at 2:32 AM, Gerd Hoffmann wrote:
>> Hi,
>>
>>> I guess -bios would load coreboot. Coreboot would siphon the data
>>> necessary for ACPI table building through the current (same) fw_cfg
>>&g
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
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
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
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 basi
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 hotpluggi
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
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 pe
On 04/08/13 17:11, Peter Maydell wrote:
> On 6 April 2013 00:52, Sriram Murthy 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
> has to be its
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
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
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
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
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
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 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 plac
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
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 thi
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
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,
>> +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
>
;> +.endianness = DEVICE_LITTLE_ENDIAN,
>> +};
>
> Looks like word writes are supported provided the memory API breaks up
> writes in little endian order. Better to make it explicit.
Like the attached incremental patch?
cheers,
Gerd
>From d46b14dfd74dcc37fe187dc76cd681ad
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.
>
&
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
Signed-off-by: Gerd Hoffmann
---
hw/vga-pci.c | 97 ++
hw
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
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 g
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-of
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
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
---
s
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
---
src/clock.
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
fies the implementation alot as we can just skip
all the tsc frequency & delta calculations.
Draft patch attached. Comments?
cheers,
Gerd
>From e42d62e90ae4b8a00413a0665d4022069154a516 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann
Date: Thu, 9 Aug 2012 13:26:18 +0200
Subject: [PATCH
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
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 th
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 (ea
Which 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
---
src/clock.c|9 +
src/paravirt.c | 90
src/parav
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 nee
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 l
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 itsel
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
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-de
real
hardware.
Signed-off-by: Gerd Hoffmann
---
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 ++---
7 files changed
growing that fast.
Signed-off-by: Gerd Hoffmann
---
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 */
#define
ucing 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 +++-
h
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:
>
>
>
>
>
>
>
>
>
> At first this worked fine,
> 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/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
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 ...
chee
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-s
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
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 hotplu
Hi,
> +/* If we don't specify the name, the bus will be addressed as .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;
> +
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 h
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 romfile=/root/rom
al times already :-(
HTH,
Gerd
commit a22fe41d90d484a68317e0ac46785611afab545f
Author: Gerd Hoffmann
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
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
> Date: Tue Nov 15 20:12:17 2011 +0200
>
> configure: build position independent executables on x86-Linux hosts
>
> PIE binaries cannot be linked with n
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\\
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
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 w
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
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, oth
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 vers
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.
ken id is maintained for -M pc-$oldqemuversion ]
Cc: Takashi Iwai
Signed-off-by: Gerd Hoffmann
---
hw/ac97.c| 16 +++-
hw/pc_piix.c | 16
2 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/hw/ac97.c b/hw/ac97.c
index 6800af4..0dbba3b 100644
--- a/
This patch adds a pc-1.0 machine type.
Signed-off-by: Gerd Hoffmann
---
hw/pc_piix.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 8c7f2b7..93e40d0 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -297,8 +297,8 @@ static
Hi,
> This is more of an edge case however, since we know that hardware tools
> rely on PCI IDs.
The ID is invalid, you can't do anything useful with it ...
> For example our hypothetical ABI signature tool will
> certainly include lspci like functionality and detect this as a change.
... exc
On 11/07/11 15:17, Avi Kivity wrote:
> On 11/07/2011 01:00 PM, 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 t
1 - 100 of 311 matches
Mail list logo
