On Tue, Jul 27, 2021 at 12:14:48PM +0200, Ard Biesheuvel wrote:
> (+ Lorenzo)
>
> On Tue, 27 Jul 2021 at 12:07, Michael S. Tsirkin wrote:
> >
> > On Tue, Jul 27, 2021 at 11:50:23AM +0200, Ard Biesheuvel wrote:
> > > On Tue, 27 Jul 2021 at 11:30, Michael S. Tsirkin
hing similar that is already implemented? Other
ideas to implement this are welcome too.
Kind regards,
Lorenzo
handler,
given that when an interrupt is raised, the new specified handler has to be
called
and its address should be retrieved in some way, that is by storing it in
the IDT.
I'm sorry, I'm a student and I'm trying to understand things,
Thank you,
Lorenzo
Il giorno gio 18 mar 2021 al
andler (for instance for
the edu device, just to try it out), it works perfectly,
meaning that the IDT is not really read-only. Do you have any idea why? Any
suggestions on how to solve the problem?
Of course I've also checked KVM_CAP_READONLY_MEM, no problem with that.
Anyway, is this the right place to post?
Thank you,
Lorenzo
x27;m not sure. Do
you think I can use this?
I see it is also use to inject something (mce), so maybe it's good to use
it.
Could you also explain to me the meaning of the ram field of the KVMSlot
struct?
Best regards,
Lorenzo Susini
Public bug reported:
The msmouse option for emulating a serial mouse does not seem to work in
a DOS guest.
I'm on Windows 10 X64, I have tried launching qemu (commit
d0cc248164961a7ba9d43806feffd76f9f6d7f41 but also way older) with:
./qemu-system-i386 -serial msmouse -fda mousetest.img
./qemu-sy
> Signed-off-by: Jon Derrick
> ---
> drivers/pci/controller/vmd.c | 44
> ++--
> 1 file changed, 38 insertions(+), 6 deletions(-)
Applied to pci/vmd, thanks.
Lorenzo
> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.
gt; > >
> > > > Please let me know your thoughts asap and I will try to at least
> > > > squeeze this patch in.
> > > >
> > > > Lorenzo
> > >
> > > Hi Lorenzo,
> > >
> > > This is fine. Please take Patch 1.
On Fri, May 29, 2020 at 03:53:37PM +, Derrick, Jonathan wrote:
> On Fri, 2020-05-29 at 11:33 +0100, Lorenzo Pieralisi wrote:
> > On Wed, May 27, 2020 at 11:02:39PM -0400, Jon Derrick wrote:
> > > Versions of VMD with the Host Physical Address shadow register use this
y wait.
Please let me know your thoughts asap and I will try to at least
squeeze this patch in.
Lorenzo
> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> index dac91d6..e386d4e 100644
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c
>
Hi Guenter,
On Fri, Jan 22, 2016 at 06:17:49PM -0800, Guenter Roeck wrote:
> On 01/13/2016 06:50 AM, Lorenzo Pieralisi wrote:
> >The Performance Monitors extension is an optional feature of the
> >AArch64 architecture, therefore, in order to access Performance
> >Monitors
ation and
restore")
Signed-off-by: Lorenzo Pieralisi
Reported-by: Guenter Roeck
Tested-by: Guenter Roeck
Cc: Will Deacon
Cc: Peter Maydell
Cc: Mark Rutland
---
v1 -> v2
- Updated the PMUVer field conditional check to take into account
future PMU versions
v1:
http://lists.
nd then we know the PMU is not present if the
> value is (signed) less than 1.
Sorry about that. Updated patch below, hopefully this time I have got
it right (I restested on Juno and QEMU and kept Guenter tested-by tag).
Please let me know.
Thanks,
Lorenzo
-- >8 --
Subject: [PATCH] arm64: ke
implements a guard by reading the ID_AA64DFR0_EL1 register
PMUVer field to detect the PMUv3 presence and prevent accessing PMUv3
system registers if the Performance Monitors extension is not
implemented in the core.
Signed-off-by: Lorenzo Pieralisi
Reported-by: Guenter Roeck
Cc: Will Deacon
Cc: Peter
On Thu, Jan 07, 2016 at 03:58:15PM +, Peter Maydell wrote:
> On 7 January 2016 at 15:53, Lorenzo Pieralisi
> wrote:
> > On Thu, Jan 07, 2016 at 01:25:35PM +, Peter Maydell wrote:
> >> We had previously been relying on the kernel not attempting to
> >> touch
s like a kernel
> bug to me. (QEMU should probably get round to implementing the PMU
> at some point for feature parity with v7, but this has not been
> a priority for us since they're not actually very useful in a
> fully emulated setup.)
Fixup patch coming, thanks.
Lorenzo
arch/arm64/boot/Image -initrd rootfs.arm64.cpio
> -no-reboot \
> -append "console=ttyAMA0"
>
> Any idea what might cause this problem and how to fix it (presumably in qemu)
> ?
We took notice of this and we are going to look into it shortly, thanks
Public bug reported:
Hi!
Apparently there's no way to install the virtio block drivers during Windows
setup, as they're simply not recognized by the installer when it looks for them
on the CD drive.
The only way to setup virtio block drivers is to first install Windows on a IDE
drive, then add
maybe I'm missing something, but is there any need to run make as the superuser
?
Lorenzo
istent with the state the VM
went throught at the time of execution of step 2.1 . If it was
possible, it would be just fine for automated daily backups.
--
Lorenzo Mancini
k to perform the online copy
between a couple of "stop" and "cont" commands, so you're sure that the
underlying .qcow2 image is frozen while you're reading it (...is it?),
but again that's suboptimal since you force the VMs to be down for some
time.
Thanks in advance!
--
Lorenzo Mancini
special-casing vvfat a bit puzzling...
vvfat is the only case in which there's any need to
override realpath() behaviour, so I tried to make it
as clear as possible.
Why is it better to affect code paths which don't need
any change?
Regards,
Lorenzo
Johannes Schindelin wrote:
Hi,
On Sun, 23 Sep 2007, Lorenzo Campedelli wrote:
I was concerned by having this handling outside of a proper place (i.e.
block-vvfat.c), but if we want to leave it there, wouldn't it be better
to just handle cases which would otherwise fail, and just try t
Johannes Schindelin wrote:
Hi,
On Sun, 23 Sep 2007, Lorenzo Campedelli wrote:
While you are working on vvfat issues, could you give a look to the
attached small patch?
Okay, this is what I would do:
- not make this handling dependent on vvfat (but this means checking if
the colon is the
be
integrated in CVS I'd be glad :)
While I'm here I'd add a related question: wouldn't it be useful to be
able to specify a per-device "-snapshot" option? Is it doable?
Thanks,
Lorenzo
--- qemu-0.9.0.20070921/block.c.orig 2007-09-21 21:10:53.0 +0200
+++ qe
s in the latest host kernel, in particular
to Dyntick, introduced in 2.6.21 (see http://lwn.net/Articles/223185/).
Does anybody know whether/how this affects qemu and kqemu operation?
Thanks in advance,
Lorenzo
Hello,
is support for the 440GX processor foreseen anytime soon?
(I noticed it i labelled with "TODO"...)
Which is the most similiar PPC processor already supported?
What are the differences (in term of things needed to support it)?
Thanks in advance,
Lorenzo
helps somebody.
Lorenzo
I doubt code in
block.c should know specific issues of different
drivers), but it works for my needs, and maybe
somebody else is interested.
The patch is agains 0.9.0.
Best Regards,
Lorenzo
--- qemu-0.9.0/block.c.orig 2007-03-10 12:53:27.0 +0100
+++ qemu-0.9.0/block.c 2007-03-10 16:22:51.00
Hi,
I tried to use the new -kernel-qemu option with the
CVS version of qemu from yesterday and kqemu-1.3.0pre3.
Is anybody interested in error reports?
As suggested on IRC, I guess only Fabrice could be,
anyway ...
Regards,
Lorenzo
___
Qemu-devel
as ;).
Thanks for your work!
Regards,
Lorenzo
Fabrice Bellard wrote:
Right, it is a regression caused by a typo in kqemu 1.3.0pre6. I just
released kqemu-1.3.0pre7 which should correct the issue. Windows 98
should also work again with it.
Regards,
Fabrice.
Lorenzo Campedelli wrote:
I see t
trace output, in case they can tell something more...
Regards,
Lorenzo
Christian MICHON wrote:
Host: winXP pro
Guest: Redhat 7.2
when kqemu (user mode) is active, "sleep 1" segfaults each time.
With kqemu disabled, no problem
--
Christian
execve("/bin/sleep", ["sleep"
32 matches
Mail list logo
