On Thu, Dec 15, 2011 at 03:53:10PM +0800, Zhi Yong Wu wrote:
I have one related question. If you build one new kernel image and
initrd from Linus' kernel git tree, and don't modify qemu, can it work
fine?
I don't understand what's your point. Unmodified QEMU should boot linux,
right?
On Thu, Dec 15, 2011 at 4:01 PM, 陳韋任 che...@iis.sinica.edu.tw wrote:
On Thu, Dec 15, 2011 at 03:53:10PM +0800, Zhi Yong Wu wrote:
I have one related question. If you build one new kernel image and
initrd from Linus' kernel git tree, and don't modify qemu, can it work
fine?
I don't
Yes. Did you build one bzImage based on Linus kernel git tree, and
then use unmodified QEMU to boot it? Can it succeed to start up?
Current buildroot (snapshot version) build linux 3.x by default, and
unmodified QEMU can boot it.
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab,
Hi all,
I want to continue the discussion about the cross page constraint on block
linking [1][2]. Max explained to me that if we link TBs belong different guest
pages, then QEMU might crash when the memory mapping is changed by tlb_set_page
(exec.c). Memory mapping changes may be the result of
I have one related question. If you build one new kernel image and
initrd from Linus' kernel git tree, and don't modify qemu, can it work
fine?
On Thu, Dec 15, 2011 at 2:57 PM, 陳韋任 che...@iis.sinica.edu.tw wrote:
Hi all,
I want to continue the discussion about the cross page constraint on
On 09/26/2011 10:13 PM, 陳韋任 wrote:
Hi, Rob
Is it just because we cannot optimize block linking which crosses page
boundary, or there are some correctness/safety issues should be considered?
If we link a TB with another TB from the different page, then the
second TB may disappear when the
Hi, Max
Sorry, I have to be sure what you talked about is guest or host.
Let me try.
Well, my explanation sucks. Let's say it other way, more precisely:
- you have two pieces of code in different pages, one of them jumps to the
other;
guest code in different guest pages.
- and you
Sorry, I have to be sure what you talked about is guest or host.
Let me try.
Well, my explanation sucks. Let's say it other way, more precisely:
- you have two pieces of code in different pages, one of them jumps to the
other;
guest code in different guest pages.
Right.
- and you
O.K., now I have to make sure it's guest virtual or guest physical.
Correct me if I am wrong.
- now you change the mapping of the code page that contains second piece
of code;
?change the mapping of the guest page which contains second piece of
guest binary. Mapping guest page to
Hi, Rob
Is it just because we cannot optimize block linking which crosses page
boundary, or there are some correctness/safety issues should be considered?
If we link a TB with another TB from the different page, then the
second TB may disappear when the memory mapping changes and the
I meant TLB change by e.g. tlb_set_page. If you change single page
mapping then all TBs in that page will be gone.
This may be the result of e.g. a page swapping, or a task switch.
You said all TBs in that page will be gone. Does it mean QEMU will
invalidate those TBs by for example,
Hi, Max
I meant TLB change by e.g. tlb_set_page. If you change single page
mapping then all TBs in that page will be gone.
This may be the result of e.g. a page swapping, or a task switch.
You said all TBs in that page will be gone. Does it mean QEMU will
invalidate those TBs by for
On 08/18/2011 04:31 AM, Max Filippov wrote:
Hi, all
I am trying to figure out why QEMU put some constraints on block
linking (chaining). Take x86 as an example, there are two places
put constraints on block linking, gen_goto_tb and cpu_exec.
- gen_goto_tb
Hi, all
I am trying to figure out why QEMU put some constraints on block
linking (chaining). Take x86 as an example, there are two places
put constraints on block linking, gen_goto_tb and cpu_exec.
- gen_goto_tb (target-i386/translate.c) ---
/* NOTE: we handle the
Hi, all
I am trying to figure out why QEMU put some constraints on block
linking (chaining). Take x86 as an example, there are two places
put constraints on block linking, gen_goto_tb and cpu_exec.
- gen_goto_tb (target-i386/translate.c) ---
/* NOTE: we handle
If we link a TB with another TB from the different page, then the
second TB may disappear when the memory mapping changes and the
subsequent direct jump from the first TB will crash qemu.
Perhaps the guest OS swap the second TB out of the guest memory,
is it what you mean?
I meant TLB
16 matches
Mail list logo
