Il 16/06/2014 18:09, John Nielsen ha scritto:
The only substantial difference on the hardware side is the CPU.
The hosts where the problem occurs use "Intel(R) Xeon(R) CPU
E5-2650 v2 @ 2.60GHz", while the hosts that don't show the
problem use the prior revision, "Intel(R) Xeon(R) CPU E5-2650 0 @
Il 16/06/2014 18:47, John Nielsen ha scritto:
On Jun 16, 2014, at 10:39 AM, Paolo Bonzini wrote:
Il 16/06/2014 18:09, John Nielsen ha scritto:
The only substantial difference on the hardware side is the CPU.
The hosts where the problem occurs use "Intel(R) Xeon(R) CPU
E5-2650 v2 @ 2.
On 16/12/2014 00:40, Oleg Ovechko wrote:
> A. Host Windows, 6 cores (no HT, turbo boost off): 6:23 (+- 10 secs)
> B. Host Windows, 1 CPU core (other are turned off in BIOS): 7:13 (+-10 secs)
> C. Host 1 core, Guest Windows 1 core: 7:15 - same as B, no degradation
> D. Host 6 cores, Guest Windows
On 16/12/2014 17:22, Oleg Ovechko wrote:
>> What is your benchmark?
>
> I've tried different ways (CrystalDiskMark 3.0.3 x64, ATTO Disk
> Banchmark v2.47) all give same result.
All are run on the AHCI passthrough disk(s), right?
> When everything is enabled in BIOS it is 6:23 on real Windows v
On 03/10/2015 00:36, Peter Maydell wrote:
>
> I agree about the (!ipv4 || !ipv6) condition though.
> The three states I listed above ought to correspond
> to "qemu_opt not set", "qemu_opt set to false" and
> "qemu_opt set to true",
The problem is that the underlying QemuOpts-based code treats "qe
On 05/10/2015 20:03, Sair, Umair wrote:
>> The first if handles the "default to N" case, the second handles "default to
>> Y", the (absent) else case handles "default to PF_UNSPEC".
>
> Can you please elaborate it. Also I am not understanding the reason for
> inverting the values of addr->has_
On 05/10/2015 20:03, Sair, Umair wrote:
>> The first if handles the "default to N" case, the second handles "default to
>> Y", the (absent) else case handles "default to PF_UNSPEC".
>
> Can you please elaborate it. Also I am not understanding the reason for
> inverting the values of addr->has_
On 12/10/2015 15:06, Sair, Umair wrote:
> Paolo, thanks for the explanation :)
>
>> > Did you test the patch, and did it work for you? If so, it is customary
>> > to reply with a line like "Tested by: Sair, Umair ".
> Yes, it worked for me. Should I reply to the email containing the patch with
On 06/04/2016 17:27, Jeff Forbes wrote:
> When I use "-cpu host,+VMX,-hypervisor", Hyper-V gives this error
> when trying to start a VM: Virtual Machine could not be started
> because the hypervisor is not running.
>
> So with the latest kernel and qemu-kvm, the hypervisor flag is
> needed.
Tha
On 06/04/2016 19:45, Jeff Forbes wrote:
> I was responding to Bandan Das' comment about Hyper-v NOT running when
> the hypervisor flag is present. What I observed was just the opposite.
> With "-cpu host,+vmx" Hyper-V will try to start the VM and then report
> that a component required by Hyper-V
On 15/10/2017 16:01, Michal Suchánek wrote:
>>> ./configure --disable-gtk --disable-sdl --disable-opengl
>> You can also use the runtime -display options (assuming
>> your development environment has the libraries
>> and your runtime environment has them installed, there's
>> no harm in having a
On 23/11/2017 12:55, Thomas Huth wrote:
> On 23.11.2017 08:36, Brendan Simon (eTRIX) wrote:
>> Hi QEMU devs,
>>
>> Just wondering when the accelerator for Apple's hypervisor.framework
>> (hvf) will hit the git repos to build and try out?
>>
>> I get the impression that patches have been submitted,
On 24/11/2017 12:58, Brendan Simon (eTRIX) wrote:
>
> Checked out the `hvf` branch, but it failed the build. Ran `mkdir build
> ; cd build ; ../configure ; make`
>
> Am I missing some definitions or command line switches?
No, I've pushed an updated version.
Paolo
On 25/11/2017 11:48, Brendan Simon (eTRIX) wrote:
> On 25/11/17 10:10 am, Brendan Simon (eTRIX) wrote:
>
>> On 24/11/17 11:39 pm, Paolo Bonzini wrote:
>>> On 24/11/2017 12:58, Brendan Simon (eTRIX) wrote:
>>>> Checked out the `hvf` branch, but it failed the b
On 07/02/2018 12:41, Brendan Simon (eTRIX) wrote:
>
> I've been pulling qemu master, building and invoking a Win 7 Pro guest
> with hvf acceleration (running on a MacBook Pro host with i7, 16GB DRAM,
> 1TB SSD).
>
> My impression is it is not as fast as it should/could be. My baseline
> is Veert
On 08/02/2018 11:21, Peter Maydell wrote:
> On 7 February 2018 at 23:05, Brendan Simon (eTRIX)
> wrote:
>> There must be some qemu developers that
>> have access to Macs and may even be Mac users too (just an assumption).
>
> Nope, pretty much not. Almost all the QEMU developers use
> Linux -- t
On 20/08/2018 15:06, Peter Maydell wrote:
> * SIG_IPI is one of the signals for specific CPU threads; so
>it is blocked in the iothread, and enabled in CPU threads
> * kvm_eat_signals() is specifically to handle SIG_IPI, and
>affects no other signal -- if the kernel returned control
>
Il 25/10/2013 14:53, jacek burghardt ha scritto:
> Is there a patch for qemu git master that pre init e1000 so I can get
> rid off unpluged network cable message ? I know there is patch but is is
> for older version of qemu and it seeem that it no longer functions and
> does not apply fully as code
Il 25/10/2013 15:53, jacek burghardt ha scritto:
> Is there a patch for qemu git master that pre init e1000 so I can get
> rid off unpluged network cable message ? I know there is patch but is is
> for older version of qemu and it seeem that it no longer functions and
> does not apply fully as code
Il 30/10/2013 18:29, Peter Maydell ha scritto:
> This looks odd -- you seem to be modifying val but then not
> using the modified value before we reach the end of the function.
>
>> > }
>> >
>> > static void
>> > @@ -445,8 +450,9 @@ set_mdic(E1000State *s, int index, uint32_t val)
>> >
Il 31/10/2013 00:54, jacek burghardt ha scritto:
> I wonder if anyone can post reworked patch to latest qemu
That's what I did 5 hours ago, though what I did was actually to look at
the bits affected by the patch and reimplement them based on the e1000
hardware spec. Can you test the second pat
Il 31/10/2013 01:21, jacek burghardt ha scritto:
> I am in process of recompiling qemu right now
> I came up with this patch is this correct
> diff -Naur qemu/hw/net/e1000.c qemu-a/hw/net/e1000.c
> --- qemu/hw/net/e1000.c 2013-10-27 15:36:05.496526538 -0600
> +++ qemu-a/hw/net/e1000.c 2013-1
On 12/11/19 16:48, Sergio Lopez wrote:
>
> Peter Maydell writes:
>
>> On Tue, 12 Nov 2019 at 15:22, Waldek Kozaczuk wrote:
>>>
>>> Hi,
>>>
>>> I am referring to the machine type described here -
>>> https://github.com/qemu/qemu/blob/master/docs/microvm.rst. I would like to
>>> know how to ini
Yes, it's a good change. The reason for the deprecation is that -accel with
colons worked only because of an implementation detail, and it conflicts
with the plans we have to improve -accel. In particular, in the next
version of QEMU the -accel option will grow more suboptions specific to KVM
or TC
On 01/04/20 18:37, Philippe Mathieu-Daudé wrote:
>
> * Refactor the open source project's existing documentation to
> provide an improved user experience or a more accessible
> information architecture.
This kind of project would be indeed very suitable to QEMU. Stefan,
perhaps you could hel
On 04/04/20 03:37, John Snow wrote:
> This looks like it could be very good for us.
>
> My only concern is that the scope and breadth of QEMU is huge and it may
> be a lot for a newcomer to tackle appropriately for top-level docs, so I
> feel like it requires a mentor who has a good understanding
On 15/05/20 12:51, Gerd Hoffmann wrote:
>> If a qtest is feasible, yes, I think we should require one for new
>> devices.
> qtest is not feasible, at least not for all kinds of devices. You can't
> talk to usb devices for example, and changing that effectively requires
> writing uhci/ohci/ehci/xhc
On 03/02/21 07:40, Kechen Lu wrote:
From the above observations, trying to see if there's a way for
enabling AVIC while also having the most optimized clock source for
windows guest.
You would have to change KVM, so that AVIC is only disabled if Auto-EOI
interrupts are used.
Paolo
On 04/02/21 13:24, Vitaly Kuznetsov wrote:
I checked Linux VMs on genuine Hyper-V and surprisingly
'HV_DEPRECATING_AEOI_RECOMMENDED' is not exposed.
Did the host have APICv/AVIC (and can Hyper-V use AVIC)? AutoEOI is
still a useful optimization on hosts that don't have
hardware-accelerated E
On 18/02/21 12:43, Alex Bennée wrote:
Kaifeng Xu writes:
Hi,
I am running QEMU in TCG mode (my server doesn't have kvm support), and I
am getting the memory traces in a x86 guest machine of all memory accesses,
including the PCID (process-context identifier, and I need that for my
current res
On 22/02/21 18:59, Kaifeng Xu wrote:
Hi,
Nice to get your replies. I am doing some research which requires me to
have some system level memory traces for all memory instructions. I want
to use that trace to do some TLB or cache studies.
Actually I don't care if I have the full PCID instructio
On 23/02/21 10:57, Jiatong Shen wrote:
Thank you very much for the answer. so if romfile on destination got
a larger size than source, why romfile check still does not
pass? because dest got enough space to hold romfile.
Because QEMU checks that memory areas have the same size on the sour
On 8/12/22 16:50, Peter Maydell wrote:
As I said previously, this is still absolutely wrong.
If we ever get to this function with either of these
fields being NULL then there has been a serious problem,
probably a memory corruption or use-after-free, or
possibly an attempt to use a partially cons
On 3/4/24 22:59, Alex Williamson wrote:
Since you're not seeing a KVM_EXIT_MMIO I'd guess this is more of a KVM
issue than QEMU (Cc kvm list). Possibly KVM doesn't emulate vmovdqu
relative to an MMIO access, but honestly I'm not positive that AVX
instructions are meant to work on MMIO space. I'
On Tue, Jun 11, 2024 at 12:39 AM Robert Henry wrote:
>
>
> Paolo:
>
> Regarding your commit to QEMU
> https://github.com/qemu/qemu/commit/69cb498c56263a5ae484fd4fef920d3d3eea04c8
>
> Four years ago I reported a bug
> https://gitlab.com/qemu-project/qemu/-/issues/249 and as part of cleaning up
>
On Mon, Aug 5, 2024 at 3:26 PM Arvid Picciani wrote:
>
> Hi,
>
> with linux 6.11 it looks like kvm SNP host api is finally there.
>
> However, current qemu upstream appears to be tested against a much
> older kernel by redhat (according to the libvirt IRC its via coconut
> svsm),
It's tested agai
36 matches
Mail list logo
