This fixes the markup of the PCI and PCIe Expander Bridge entries to be
consistent with the rest of the file.
Signed-off-by: George Matsumura
---
docs/specs/pci-ids.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/specs/pci-ids.rst b/docs/specs/pci-ids.rst
index
Add the missing devices 1b36:000c (PCIe root port) and 1b36:000e
(PCIe-to-PCI bridge).
Signed-off-by: George Matsumura
---
docs/specs/pci-ids.rst | 4
1 file changed, 4 insertions(+)
diff --git a/docs/specs/pci-ids.rst b/docs/specs/pci-ids.rst
index c0a3dec2e7..0de13de1e4 100644
--- a
other resources that could help us learn more about this aspect of
QEmu.
Ideally we would like to be able to find places in the code that run every
time a VM is initialized and launched, and be able to acquire some data
from those functions for logging/printing/etc.
Thank you in advance,
George
version, so if you want you can backport
> that patch in your version, the change should be simple.
Anthony,
Is this the kind of thing we could / should cherry-pick onto our qemu-upstream
branches (both 4.14 and 4.15)?
-George
current command, check for a pending command on the queue and if one
exists call lsi_reselect().
Signed-off-by: George Kennedy
---
Thanks again Paolo,
Your latest suggested fix reduces the patch even further. Now there's
no need for a "pending" flag.
(Will try to find the intermedi
-off-by: George Kennedy
---
Thanks Paolo,
Your latest suggestion was the "missing link". Calling lsi_wait_reselect()
after a WAIT DISCONNECT Script instruction when there are commands on
the pending queue is all the is needed. The patch has been greatly
reduced in size and complexity.
instead with the pointer to the Reselection Scripts. When
Reselection has completed, restore the original DSP contents.
Signed-off-by: George Kennedy
---
Thanks Paolo,
Sorry for missing your suggested fix. I believe the Script intercept is now
being done as you had suggested.
hw/scsi
On 11/6/2018 1:58 PM, Paolo Bonzini wrote:
On 31/10/2018 22:03, George Kennedy wrote:
+#define SCRIPTS_LOAD_AND_STORE 0xe2340004
I'm very confused. Why did this constant reappear?
Ok. Me too.
What are you proposing instead and I'll change it to that?
Did I have what you
. When Reselection has completed, restore the original DSP contents.
Signed-off-by: George Kennedy
---
Thanks Paolo,
For the question about why the "- 8" in "s->resel_dsp = s->dsp - 8". Notice
that at the beginning of lsi_execute_script() just before the
"switch
On 10/31/2018 5:21 AM, Paolo Bonzini wrote:
On 30/10/2018 22:42, George Kennedy wrote:
Under heavy IO (e.g. fio) the queue is not checked frequently enough for
pending commands. As a result some pending commands are timed out by the
linux sym53c8xx driver, which sends SCSI Abort messages for
. When Reselection has completed, restore the original DSP contents.
Signed-off-by: George Kennedy
---
hw/scsi/lsi53c895a.c | 51 ---
1 file changed, 40 insertions(+), 11 deletions(-)
diff --git a/hw/scsi/lsi53c895a.c b/hw/scsi/lsi53c895a.c
index
On 10/23/2018 6:31 PM, Paolo Bonzini wrote:
On 24/10/2018 00:11, George Kennedy wrote:
What about "req->hba_private != s->current"? That should cause a call
to lsi_queue_req, and then you can check s->want_resel in lsi_queue_req.
For the extended period of time where lsi
On 10/23/2018 5:50 PM, Paolo Bonzini wrote:
On 23/10/2018 23:36, George Kennedy wrote:
On 10/23/2018 10:33 AM, Paolo Bonzini wrote:
On 22/10/2018 23:28, George Kennedy wrote:
As you suggested I moved the loading of "s->resel_dsp" down to the
"Wait Reselect"
c
On 10/23/2018 10:33 AM, Paolo Bonzini wrote:
On 22/10/2018 23:28, George Kennedy wrote:
As you suggested I moved the loading of "s->resel_dsp" down to the "Wait
Reselect"
case. The address of the Reselection Scripts, though, is contained in "s->dsp -
8&quo
Reselection
Scripts. When Reselection has completed, restore the original DSP contents.
Signed-off-by: George Kennedy
---
Thank you for reviewing, Paolo,
As you suggested I moved the loading of "s->resel_dsp" down to the "Wait
Reselect"
case. The address of the Reselect
Reselection
Scripts. When Reselection has completed, restore the original DSP contents.
Signed-off-by: George Kennedy
---
hw/scsi/lsi53c895a.c | 94 ++--
1 file changed, 91 insertions(+), 3 deletions(-)
diff --git a/hw/scsi/lsi53c895a.c b/hw/scsi
Just to be sure, I repeated it, with the same result. I have the
impression that it might be the time spent between a vmentry and a
vmexit that matters in the CPU performance of the guest. I am no expert
though.
This is what I am seeing in the graphs:
vmentryinterval A(s)vmexitinterva
I also tried to give ESXi a try. VMware lets me download only 6.7 from
their site. Although I have a workstation motherboard (Supermicro
X9SRA), it won't let me start a VM with IOMMU enabled, it complains
about failing to register the passthrough GPU.
--
You received this bug notification because
spec-ctrl triggers vmentries/vmexits much more often
than the VM with spec-ctrl. I could not spot a difference in the pattern of the
vmentries/vmexits themselves (snapshot_2 below), only their frequency seems to
differ.
Does anybody have an idea of what is going on?
George
** Attachment added
snapshot_2 showing the pattern of vmentries/vmexits from the previous
comment ("zoom-in").
** Attachment added: "snapshot_2.png"
https://bugs.launchpad.net/qemu/+bug/1788665/+attachment/5190356/+files/snapshot_2.png
--
You received this bug notification because you are a member of qemu-
deve
It seems that this "bug" affects only 2D-performance mediated through
GDI in Windows (CPU-, not GPU-driven). There have been reports that GDI
switches a lot between user/kernel space.
Are vmexits triggered when the guest switches from user- to kernel-
space? Could this be subsequently causing IRBS
Yes, it's an Nvidia GTX 1060 6GB with PCI passthrough to a Windows 1803
KVM guest. As far as I can tell my setup is very similar to Heiko's,
only I am using libvirt, not qemu directly.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
h
I did a git-bisect between 4.14.18(bad) and 4.14.10(good).
Unsurprisingly, this is the first "bad" commit:
KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL
commit d28b387fb74da95d69d2615732f50cceb38e9a4d
George
--
You received this bug notification because you are a memb
17.19 with CONFIG_DEBUG_INFO=y.
However I cannot see any differences while running "perf top" in the
host between the affected/unaffected version of windows. CPU usage seems
to be the same.
Any hints would be greatly appreciated.
Best,
George
--
You received this bug notification because y
Whenever I append `console=ttyAMA0` I get kernel panic `Division by zero
in kernel` and -serial stdio doen't seem to work.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1772165
Title:
qemu-system-a
Serial terminal doesn't work with this options. Would you provide
options with which i'll be able to access and login into the terminal.
SSH is also a good solution.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchp
I need this for raspberry pi emulation and the most recent doesn't work
as you can see from my other bug post.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1772166
Title:
qemu 2.4.1: dereferencing
How then should I be able to actually use the vm when there is no input?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1772165
Title:
qemu-system-arm: -device usb-
host,bus=001,vendorid=0x04f2,pr
Public bug reported:
Trying to compile qemu release 2.4.1
Getting compile error
user-exec.c: In function ‘cpu_resume_from_signal’:
user-exec.c:72:37: error: dereferencing pointer to incomplete type ‘struct
ucontext’
sigprocmask(SIG_SETMASK, &uc->uc_sigmask, NULL);
qemu-system-arm -M raspi2 -append "rw earlyprintk loglevel=8
dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" -cpu arm1176 -dtb
bcm2709-rpi-2-b.dtb -hda DietPi_v6.8_RPi-ARMv6-Stretch.img -kernel
kernel7.img -m 1G -smp 4 -serial stdio -usb -device usb-
host,bus=001,vendorid=0x1d6b,productid=0x0002
** Tags
Public bug reported:
Using Qemu 2.12.0 on ArchLinux.
Trying to emulate arm device with `qemu-system-arm` and attach usb
device for unput using
` -usb -device usb-host,bus=001,vendorid=0x1d6b,productid=0x0002 `
# lsusb returns
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 0
pdate
glib have a number of options, so I personally don't see any grounds
for objecting or complaining. Thanks again for the heads-up.
-George
CentOS 6.
Tailing into that, with my CentOS package maintainer hat on: You said
that the code in question compiled on RHEL 6 because RH had backported
the function in question. Will QEMU continue to actually compile on
RHEL 6 / CentOS 6? I.e., will configure be checking for that
function, or only checking for the version number?
If the former, then the CentOS 6 Xen packages won't be affected. If
the latter, then at some point I'll have to stop updating the Xen
version for CentOS 6 -- but as the CentOS 6 EOL is coming up in 2020,
it shouldn't be too much of a hardship.
-George
Thank you Paolo,
"Signed-off-by: George Kennedy"
George
On 12/11/2017 11:55 AM, Paolo Bonzini wrote:
On 11/12/2017 17:45, George Kennedy wrote:
The LSI 53c895a code does not handle the PPR Extended Message. Add
support to handle PPR Extended Message like SDTR and WDTR are handle
The LSI 53c895a code does not handle the PPR Extended Message. Add
support to handle PPR Extended Message like SDTR and WDTR are handled.
That is, to skip past the message bytes and ignore the message.
---
hw/scsi/lsi53c895a.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/scsi/lsi
The LSI 53c895a code does not handle the PPR Extended Message. Add support to
handle PPR
Extended Message like SDTR and WDTR are handled. That is, to skip past the
message
bytes and ignore the message.
---
hw/scsi/lsi53c895a.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/scsi/lsi
For s390x, the hang definitely still occurs using a chroot with qemu-
s390x-static copied in and no QEMU_LD_PREFIX. I'm not in a good position
to test other big-endian architectures though.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QE
I think I hit this problem trying to use qemu-s390x-static in the
s390x/ubuntu:16.04 docker image. Running qemu-s390x-static 2.9.0 on
binaries in that image (e.g. /bin/echo) results in a hang.
I've noticed that doing the same in a s390x/debian:jessie image does NOT
have the same problem. No hang.
;t know if do the same without this patch)
> Scsi disk case not tested for now.
>
> Any comment is appreciated.
I think what's missing in this changelog is why we want this patch --
what's the advantage? Was some of the functionality above not working
before, for example?
-George
Same code for FreeBSD on older devices under openstack/qemu:
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
QEMU_AUDIO_DRV=none /usr/bin/kvm -name instance-0968 -S -machine
pc-i440fx-1.5,accel=kvm,usb=off -cpu host -m 2096 -realtime mlock=off -smp
1,sockets=1,core
.
Signed-off-by: Roger Pau Monné
Reported-by: George Dunlap
Tested-by: George Dunlap
Unmap persistent grants before switching to the closed state, so the
frontend can also free them.
Signed-off-by: Roger Pau Monné
Reported-and-Tested-by: George Dunlap
Cc: Stefano Stabellini
Cc: Kevin Wolf
Cc: Stefan Hajnoczi
Cc: George Dunlap
CC'ing Konrad and Stefano: This fixes a cr
Nahanni's poor current development coupled with virtIO's promising
expansion was what encouraged us to explore virtIO-serial [1] for
inter-virtual machine communication. Though virtIO-serial as it is
isn't helpful for inter-VM communication, some work is needed for this
purpose and this is exactly
7;t focus on everything, though.
>
> Anyway, ivshmem didn't make the cut for RHEL-7.0. Sorry if that
> inconveniences you. To get it into RHEL, you need to show it's both
> useful and supportable. Building a community around it would go a long
> way towards that.
>
> If you want to discuss this in more detail with us, you may want to try
> communication channels provided by your RHEL subscription in addition to
> the QEMU development mailing list. Don't be shy, you're paying for it!
>
> As always, I'm not speaking for myself, not my employer.
>
> Okay, wearing my QEMU hat again.
>
> >> In short, create a viable community around ivshmem, either within the
> >> QEMU community, or separately but cooperating.
> >
> > At least, DPDK.org community is a community using it.
>
> Using something isn't the same as maintaining something. But it's a
> necessary first step.
>
> [...]
>
>
--
Thanks and regards,
Jobin Raju George
Final Year, Information Technology
College of Engineering Pune
Alternate e-mail: georgejr10...@coep.ac.in
me testing. :)
--
George-Cristian Bîrzan
an do anything other than apologize.
(And of course see if there *is* a way to actually get it upstream.)
-George
copying the vendor CPU
information from the host CPU when either the qemu32 or qemu64 CPU is
being used.
|
Signed-off-by: George Yunaev
---
--- qemu.old/target-i386/cpu.c 2014-03-10 23:47:08.0 -0700
+++ qemu/target-i386/cpu.c 2014-03-10 23:47:32.433412520 -0700
@@ -1863,7
On Tue, Feb 25, 2014 at 2:42 PM, Peter Maydell wrote:
> On 25 February 2014 04:15, Jobin Raju George wrote:
> > On Mon, Feb 24, 2014 at 5:54 PM, Peter Maydell >
> > wrote:
> >> Why not just do the git submodule command that the error message
> >> from c
On Mon, Feb 24, 2014 at 5:54 PM, Peter Maydell wrote:
> On 21 February 2014 21:41, Jobin Raju George wrote:
> > To fix this issue:
> >
> > I cloned dtc from its repository and extracted the tarball to qemu/dtc/.
>
> Why not just do the git submodule command th
n Raju George wrote:
> I am trying to compile qemu from source to get my hands dirty with its
> development. I cloned the package from the
> repository<http://git.qemu-project.org/?p=qemu.git;a=snapshot;h=refs/heads/master;sf=tgz>.
> I extracted the tarball and started with
id not resolve the error.
There is a similar question I have seen but this too could not solve the
error I am facing:
- "ERROR: zlib check failed" while compiling
Qemu<http://askubuntu.com/questions/335875/error-zlib-check-failed-while-compiling-qemu>
--
Thanks and regar
line patch -- do you have that
patch applied to your copy of qemu?
-George
e floppy disk thing: if you don't specifically
tell qemu that you do *not* want a cdrom, it will give you one; but
since xl doesn't know anything about it, you can't actually use it.
It seems like there needs to be a "--no-default-devices" option for
qemu that will say, "No really, only put in what I ask you to put in."
>
> Supporting spice in PV guests would be hard, because spice needs QXL
> that is a PCI device. PV guests don't have a PCI bus. Of course if
> somebody did the work to make QXL and spice work with PV guests I would
> be happy to accept it.
If I recall correctly, isn't part of the problem that the PCI access
essentially requires synchronous communication via MMIO accesses?
We'd basically have to add a device model and MMIO handling to PV
guests. Possible but far from simple. (Possibly easier for PVH
domains once they come out.)
-George
On Mon, Aug 19, 2013 at 3:47 PM, Liu, Jinsong wrote:
> Ping?
I know Ian and Stefano are doing something at ARM this week -- Anthony
might be able to give a review, at least...
-George
On Mon, Aug 5, 2013 at 4:06 PM, Gonglei (Arei) wrote:
>> -Original Message-
>> From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of George
>> Dunlap
>> Sent: Monday, August 05, 2013 10:28 PM
>> To: Gonglei (Arei)
>> Cc: xen-de...@lists.xen
pa = 0x000a1fc0 mfn =
> 0x qual = 0x0182 p2mt = 0x0004 ]
> CPU2 0 (+ 0) NPF [ gpa = 0x000a1fe0 mfn =
> 0x qual = 0x0182 p2mt = 0x0004 ]
>
> Please see attachment for more information.
>
> Because of the lot's of VMEXIT, the cirrus_vga_ioport_write funciton receive
> little scheduling,
> and cirrus_vga_write_gr execution interval of more than 32ms twice per, so
> that the blank screen time over 13 second with upstream qemu on Xen.
> I don't know why the Windows XP guest access the memory region
> 0xa~0xa with upstream qemu but with traditional qemu-dm is not,
> Anyone can give me some suggestion?
Anthony Perard is probably the best person to answer this question,
but unfortunately he's on holiday at the moment.
It might be interesting to see what xenalyze tells you about what it
sees in the trace:
http://blog.xen.org/index.php/2012/09/27/tracing-with-xentrace-and-xenalyze/
I think you'll want to use "--summary --with-mmio-enumeration".
-George
On 18/07/13 12:09, Ian Jackson wrote:
Fabio Fantoni writes ("Re: [PATCH v3] libxl: usb2 and usb3 controller support for
upstream qemu"):
Il 12/07/2013 17:33, George Dunlap ha scritto:
On 12/07/13 13:36, Fabio Fantoni wrote:
[someone wrote:]
I'm just curious, why is this so c
he "id=usb" component.
-George
On 12/07/13 13:36, Fabio Fantoni wrote:
Il 12/07/2013 13:06, George Dunlap ha scritto:
On 12/07/13 11:22, Fabio Fantoni wrote:
Usage: usbversion=1|2|3 (default=2)
Specifies the type of an emulated USB bus in the guest. 1 for usb1,
2 for usb2 and 3 for usb3, it is available only with upstream
On 12/07/13 11:22, Fabio Fantoni wrote:
Usage: usbversion=1|2|3 (default=2)
Specifies the type of an emulated USB bus in the guest. 1 for usb1,
2 for usb2 and 3 for usb3, it is available only with upstream qemu.
Default is 2.
Signed-off-by: Fabio Fantoni
---
docs/man/xl.cfg.pod.5 |6
On 14/06/13 15:14, George Dunlap wrote:
On 14/06/13 12:34, Ian Campbell wrote:
On Fri, 2013-06-14 at 11:53 +0100, George Dunlap wrote:
On Thu, Jun 13, 2013 at 6:22 PM, Ian Campbell
wrote:
On Thu, 2013-06-13 at 17:55 +0100, Stefano Stabellini wrote:
We could have a xenstore flag somewhere
On 14/06/13 12:34, Ian Campbell wrote:
On Fri, 2013-06-14 at 11:53 +0100, George Dunlap wrote:
On Thu, Jun 13, 2013 at 6:22 PM, Ian Campbell wrote:
On Thu, 2013-06-13 at 17:55 +0100, Stefano Stabellini wrote:
We could have a xenstore flag somewhere that enables the old behaviour
so that
root problem is that if we revert this patch, and someone
passes through a pci device using qemu-xen (the default) and the MMIO
hole is resized, at some point in the future qemu will randomly die.
If it's a choice between users experiencing, "My VM randomly crashes"
and experiencing, "I tried to pass through this device but the guest
OS doesn't see it", I'd rather choose the latter.
-George
On 13/06/13 16:36, Ian Campbell wrote:
On Thu, 2013-06-13 at 16:30 +0100, George Dunlap wrote:
On 13/06/13 16:16, Ian Campbell wrote:
On Thu, 2013-06-13 at 14:54 +0100, George Dunlap wrote:
On 13/06/13 14:44, Stefano Stabellini wrote:
On Wed, 12 Jun 2013, George Dunlap wrote:
On 12/06/13 08
On 13/06/13 16:16, Ian Campbell wrote:
On Thu, 2013-06-13 at 14:54 +0100, George Dunlap wrote:
On 13/06/13 14:44, Stefano Stabellini wrote:
On Wed, 12 Jun 2013, George Dunlap wrote:
On 12/06/13 08:25, Jan Beulich wrote:
On 11.06.13 at 19:26, Stefano Stabellini
wrote:
I went through the
t was a bad idea and so were letting someone else
bring it up -- or maybe hoping no one would remember to bring it up. :-)
(Obviously the decision needs to be made in public, but sometimes having
technical solutions hashed out in a face-to-face meeting is more efficient.)
-George
On 13/06/13 14:44, Stefano Stabellini wrote:
On Wed, 12 Jun 2013, George Dunlap wrote:
On 12/06/13 08:25, Jan Beulich wrote:
On 11.06.13 at 19:26, Stefano Stabellini
wrote:
I went through the code that maps the PCI MMIO regions in hvmloader
(tools/firmware/hvmloader/pci.c:pci_setup) and it
a mechanism to do memory hot-plug in qemu at the moment? If
not, then there's no reason to put it anywhere else.
-George
On 12/06/13 11:11, Jan Beulich wrote:
On 12.06.13 at 12:05, George Dunlap wrote:
On 12/06/13 08:25, Jan Beulich wrote:
On 11.06.13 at 19:26, Stefano Stabellini
wrote:
I went through the code that maps the PCI MMIO regions in hvmloader
(tools/firmware/hvmloader/pci.c:pci_setup) and it looks
limitations. However, in #1, *no* guests will
be able to access the device. At least in #2, *many* guests will be
able to do so. In any case, apparently #2 is what KVM does, so having
the limitation on guests is not without precedent. It's also likely to
be a somewhat tested configuration (unlike #3, for example).
-George
passthrough bug:
http://marc.info/?l=xen-devel&m=136242365010750
Re the release:
Acked-by: George Dunlap
efore we wouldn't have this problem.
Maybe we should prevent HVM guest migration without PV drivers with xl
too. Ian, what do you think?
We should be able to make it safe if we just make sure that qemu does a
metadata sync / FS sync when we ask qemu to write the save file.
-George
On Tue, Mar 19, 2013 at 3:12 PM, George Dunlap
wrote:
> > I've just had a chat with Stefano, and it turns out I was a bit
> confused -- this change has nothing to do with qemu running as a
> device model, but only as qemu running as a PV back-end for PV guests.
> So the que
On Tue, Mar 19, 2013 at 11:21 AM, George Dunlap
wrote:
> On 03/19/2013 11:14 AM, Paolo Bonzini wrote:
>>
>> Il 19/03/2013 11:51, George Dunlap ha scritto:
>>>
>>> On 03/19/2013 10:43 AM, Paolo Bonzini wrote:
>>>>>>
>>>>>> E
On 03/19/2013 11:14 AM, Paolo Bonzini wrote:
Il 19/03/2013 11:51, George Dunlap ha scritto:
On 03/19/2013 10:43 AM, Paolo Bonzini wrote:
Even for successful migration, it would also be bad for downtime (QEMU
isn't exactly lightning-fast to start). And even if failure weren't
catast
that just means we'd have to add a
hook to the callback to save qemu state, to sync the metadata at that
point, right? (This may in fact already be done; I'm more or less
completely unfamiliar with the qemu side of save/restore.)
-George
On Mon, Mar 18, 2013 at 6:00 PM, Paolo Bonzini wrote:
> Il 18/03/2013 18:38, George Dunlap ha scritto:
>>>>
>>> This might be a difference between Xen and KVM. On Xen migration is
>>> made to a server in a paused state, and it's only unpaused when
>>
en the migration starts.)
If so I think that should answer Paolo's argument -- but let me go
through and verify that first.
It will have to wait until tomorrow, however. :-)
-George
Anthony Liguori wrote on 05/01/2012 06:45:47 PM:
> Anthony Liguori
> 05/01/2012 06:45 PM
>
> To
>
> George Wilson/Austin/IBM@IBMUS
>
> cc
>
> Paul Moore , qemu-devel@nongnu.org
>
> Subject
>
> Re: [Qemu-devel] [PATCH] vnc: disable VNC password authe
Anthony Liguori wrote on 05/01/2012 06:26:05 PM:
> Anthony Liguori
> 05/01/2012 06:26 PM
>
> To
>
> Paul Moore
>
> cc
>
> qemu-devel@nongnu.org, George Wilson/Austin/IBM@IBMUS
>
> Subject
>
> Re: [Qemu-devel] [PATCH] vnc: disable VNC password authe
, it's better to use that and minimize privilege by
limiting the SELinux policy addition to a single affected release.
Regards,
George Wilson
IBM Linux Technology Center
Security Architect & Team Lead
512-286-9271
Here's the patch after suggested changes.
---
target-arm/cpu.h |1 +
target-arm/helper.c|3 +++
target-arm/translate.c | 16 +---
3 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 4a1c53f..8751402 100644
--- a/ta
---
target-arm/cpu.h |1 +
target-arm/helper.c|3 +++
target-arm/translate.c | 17 +++--
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 4a1c53f..8751402 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -
up/down count can also be made runtime configurable, since, again, some
targets implement up counters. The logic is all the same in that
case, with just a difference in sign...
>
--
Regards,
George
_ __o George G. Davis - Software Engineer (o>
----\<, M
*~ */*~
+ rm -f cscope.*
$(MAKE) -C tests clean
for d in $(TARGET_DIRS); do \
$(MAKE) -C $$d $@ || exit 1 ; \
--
Regards,
George
state.
>
> Oops, sorry. Should be fixed now.
Works for me now, thanks!
--
Regards,
George
I've
> a few other uses in the pipeline.
.../qemu/hw/arm_timer.c:25: syntax error before "ptimer_state"
.../qemu/hw/arm_timer.c:25: warning: no semicolon at end of struct or union
Current CVS is missing definition for ptimer_state.
--
Regards,
George
_ __o Geo
87 matches
Mail list logo
