Nguyen Anh Quynh wrote:
Hi,
I am thinking about comibing this ROM with the extboot. Both two ROM
are about booting, so I think that is reasonable. So we will have
only 1 ROM that supports both external boot and Linux boot.
Is that desirable or not?
Does it make the code simpler and
Nguyen Anh Quynh wrote:
Actually, this code is left from the original code of Anthony, and it
seems he took it from qemu 0.8 version.
Anthony, may you explain why you want to hijact the linux boot process
here? If I understand correctly, we can just let the original int19
execute, and if
Nguyen Anh Quynh wrote:
Actually, this code is left from the original code of Anthony, and it
seems he took it from qemu 0.8 version.
Anthony, may you explain why you want to hijact the linux boot process
here? If I understand correctly, we can just let the original int19
execute, and if
Anthony Liguori wrote:
The thinking is to eliminate the need to hijack the boot sector when
using the -kernel option. However, the linux boot stuff in extboot has
been broken since hpa rewrote the boot code. It can be removed for now
and I'll eventually revisit it.
It probably makes
Anthony Liguori wrote:
Nguyen Anh Quynh wrote:
The thinking is to eliminate the need to hijack the boot sector when
using
the -kernel option.
I see, but does that offer any advantage over the current approach?
You no longer have to specify a -hda option when using -kernel.
Nguyen Anh Quynh wrote:
This patch replaces the current assembly code of Extboot option rom
with new C code. Patch is against kvm-66.
This version returns an error code in case int 13 handler cannot
handle a requested function.
Signed-off-by: Nguyen Anh Quynh [EMAIL PROTECTED]
+
+ .globl linux_boot
+linux_boot:
+ cli
+ cld
+ mov $0x9000, %ax
+ mov %ax, %ds
+ mov %ax, %es
+ mov %ax, %fs
+ mov %ax, %gs
+ mov %ax, %ss
+ mov $0x8ffe, %sp
+ ljmp $0x9000 + 0x20, $0
The hard use of segment 9000 is really highly unfortunate
Avi Kivity wrote:
Kevin O'Connor wrote:
I have been working on a port of bochs bios to gcc. This port is
nearly complete. The new code does not rely on bcc or dev86.
Instead, it uses standard gcc and gas. It should compile on any
recent Linux distribution.
I'm sending this email because
Kevin O'Connor wrote:
On Sun, Apr 06, 2008 at 11:42:11PM -0700, H. Peter Anvin wrote:
bcc is truly horrible. gcc is, of course, best, although it does produce
bloated 16-bit code.
With gcc, the text size has actually been significantly reduced - I'm
not sure if this is because I'm using
Christian Borntraeger wrote:
Rusty,
currently virtio_blk uses one major number per device. While this works
quite well on most systems it is wasteful and will exhaust major numbers
on larger installations.
This patch allocates a major number on init and will use 16 minor numbers
for each
Anthony Liguori wrote:
Christian Borntraeger wrote:
Rusty,
currently virtio_blk uses one major number per device. While this works
quite well on most systems it is wasteful and will exhaust major numbers
on larger installations.
This patch allocates a major number on init and will use 16
Tomas Rusnak wrote:
Chris Wedgwood napsal(a):
On Thu, Feb 28, 2008 at 10:11:30AM +0100, Tomas Rusnak wrote:
Check 'man lilo.conf' under 'disk=' and 'max-partitions='
Thank you for your quick answer, but this doesn't help. After i run
lilo, it give me the same error message.
did you try
Avi Kivity wrote:
H. Peter Anvin wrote:
Just for fun, I tried to boot OS/2 Warp 4.0 under KVM (KVM-59 with the
latest git kernel from Linus as of yesterday, slightly post
2.6.24-rc8.)I found that it crashes very early, apparently because
KVM doesn't handle an #UD received in user mode
Just for fun, I tried to boot OS/2 Warp 4.0 under KVM (KVM-59 with the
latest git kernel from Linus as of yesterday, slightly post 2.6.24-rc8.)
I found that it crashes very early, apparently because KVM doesn't
handle an #UD received in user mode. It appears that OS/2 actually
provokes an
David P. Reed wrote:
I believe (though no one seems to have confirming documentation from the
chipset or motherboard vendor) that port 80 is actually functional for
some unknown function on these machines. (They do respond to in
instructions faster than a bus cycle abort does - more
Carsten Otte wrote:
Christian Borntraeger wrote:
It is not yet updated to latest virtio latest kvm.
This version uses a pci device for virtio. Since I'm think Rusty's
config space does not matches
pci config space I might consider changing it. (Preferably not, maybe
I'll start using it
Glauber de Oliveira Costa wrote:
From: Glauber de Oliveira Costa [EMAIL PROTECTED]
tsc is very good time source (when it does not have drifts, does not
change it's frequency, i.e. when it works), so it should have its rating
raised to a value greater than, or equal 400.
Since it's being a
Jorge Lucángeli Obes wrote:
The '#!' trick works nice with scripts, but I don't see it playing
very well with images. ¿Comments? ¿Pointers?
Well, you can make it work with a header (you just have to pad it out to
a fixed length or use a variable-offset format), but binfmt_misc might
be a
Andi Kleen wrote:
No processors that support KVM exist that also do not support CMPXCHG64,
so no additional check is necessary. This setup allows for a single kernel
that will boot on i486 and also support KVM if available.
The CONFIG should only control the early CPUID checks, which are
Rusty Russell wrote:
Intel manual (and KVM definition) say it's TPR is 4 bits wide. Also fix
CR8_RESEVED_BITS typo.
Signed-off-by: Rusty Russell [EMAIL PROTECTED]
Indeed it is.
Acked-by: H. Peter Anvin [EMAIL PROTECTED]
-hpa
Avi Kivity wrote:
X86_CR8_TPR is not used in the kernel. But is this meant to be a mask,
or something else?
Yes, a mask.
And no, it's not used, except for KVM...
-hpa
-
This SF.net email is sponsored by DB2
Jeremy Fitzhardinge wrote:
The completely identical device model is of course ideal, but the
implementation and consolidation of that is a long term prospect to
move towards, not something that will happen immediately. We at least
emulate physical hardware devices already, and will continue
Axel Kittenberger wrote:
Unfortunally all machines detect the same ethernet address
'52:54:00:12:34:56'. Which you can guess what i means, networking comes
and goes whatever machine last the ethernet address got hold of from the
gateway. I tried specifing an ethernet-adress with -net
Ulrich Drepper wrote:
Stephane Eranian wrote:
They use cpuid. I expect more and more applications/OS will rely on
performance counters to boost performance at runtime.
That's a definitive fact. ld.so for the longest time selects special
DSOs to load automatically based on the data. String
S.Çağlar Onur wrote:
g means r+i so the register allocator in the -O0 case is selecting r
while in the optimize case is selecting i
g means rmi, not ri.
-hpa
-
Take Surveys. Earn Cash. Influence the Future of
25 matches
Mail list logo
